From kontola@nmpies01tr.nmp.nokia.com Thu Jun 15 05:47:20 1995
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id FAA06719 for <hfsig@tapr.org>; Thu, 15 Jun 1995 05:47:15 -0500
Received: from saeda11.nmp.nokia.com (saeda11.nmp.nokia.com [131.228.240.201]) by noknic.nokia.com (8.6.9/8.6.9) with SMTP id NAA15101 for <hfsig@tapr.org>; Thu, 15 Jun 1995 13:45:14 +0300
Received: from ms-smtp-gw.nmp.nokia.com by saeda11.nmp.nokia.com with SMTP
	(1.37.109.8/16.2) id AA02056; Thu, 15 Jun 1995 13:46:06 +0300
Received: by ms-smtp-gw.nmp.nokia.com with Microsoft Mail
	id <2FE01D36@ms-smtp-gw.nmp.nokia.com>; Thu, 15 Jun 95 13:44:54 gmt
From: "Kontola Ilkka (NMP)" <kontola@nmpies01tr.nmp.nokia.com>
To: hfsig <hfsig@tapr.org>
Subject: some questions
Date: Thu, 15 Jun 95 13:41:00 gmt
Message-Id: <2FE01D36@ms-smtp-gw.nmp.nokia.com>
Encoding: 37 TEXT
X-Mailer: Microsoft Mail V3.0


This is my first posting to the list so please forgive me my ignorance.

What kind of delay spread there is on NVIS paths? The ground wave could be 
one path but is there ionospheric multipath modes in NVIS (of course in 
addition to the _wanted_ ionospheric refraction/reflection)?

I have no hands-on experience on _HF_ digital modulations - exept CW ;-).

In literature there are often casual comments ".... on 3.5 MHz packet the
multipath is very severe problem ...." and so on. Are the article/book 
authors
referring to DX or multi-hop paths or shorter ranges?

Pointers to existing DSP5600X classic modem codes  (RTTY, AMTOR, PACTOR, 300 
bps FSK / "HF packet") as well as a pointer to a PC PACTOR program 
(requiring only a modulator and demodulator) would be appreciated!

I would like to get some feeling about the classic HF digital modes but I 
dont want to spend much time coding soon-to-become-obsolete modems and 
protocol software.

Is anyone working with adaptive equalizer -based HF modem?

BTW I have two DSP56000-family development systems:
 - Ariel PC-56 (an ISA card with a 14-bit codec and a 20 MHz 56001)
 - DSP56002EVM (two days old.... not much experience yet)

73,
Ilkka OH3NJC

*********************************************************************
Ilkka Kontola                   E-Mail: ilkka.kontola@nmp.nokia.com
Nokia Mobile Phones
Cellular Data
Tampere, Finland

From FORRERJ@frl.orst.edu Thu Jun 15 10:50:29 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA08573 for <hfsig@tapr.org>; Thu, 15 Jun 1995 10:50:25 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA22721 for <hfsig@tapr.org>; Thu, 15 Jun 1995 08:49:52 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 15 Jun 95 8:56:05 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 15 Jun 95 8:55:57 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 15 Jun 1995 08:55:52 PST8PDT
Subject:       Re: [HFSIG:400] some questions
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <27F55CE0C08@frl.orst.edu>

Dear Ilkka,

To be honest, I don't really know what "NVIS" means - can anyone help?

Just for interest sake, you may find it useful to browse the files in
ftp.tapr.org /tapr/SIG/hfsig/upload
There are quite a bit on HF propagation; as related to it's affects on
digital transmissions.

You will also find two Pactor programs there, one that I wrote "PSATOR/PSA-
PACTOR" for the sound card DSP, and another one by Tom Sailer, HB9JNX, that 
will work with a number of different types of modems, including something 
that you can put together on your new EVM56002.

I have ported the Alef Null kernel to the EVM56002 and thus allows you
to run any of the codes that run on the DSPCARD4. This includes 1200 baud
BELL 202 and 9600 baud PAM (G3RUH) style modems. The DSP kernel includes 
all HDLC and KISS interfaces, so all you need to have is the EVM and 
one of the flavors of NOS/KA9Q on your PC. It's really neat stuff. For the 
HF side of things, I have some HF modems for the EVM as well. 

Using the ported kernel, you will also be able to participate in the
experimental high speed HF modem work. There also are a number of 
excellent noise reduction programs using Wiener, LMS and correltion-
based algorithms. The latter is by Pawel (SP9VRC) and is a joy to use on 
CW. 

I am working on putting together the schematic for my version of the EVM's 
radio interface and will post the complete package (with the kind 
permission of the Alef Null group) on the net. Watch for the announcement if 
you are interested.

Think this answers most of your questions. Feel free to e-mail me directly 
about the EVM56002.

73's

--Johan, KC7WW
(email: forrerJ@ucs.orst.edu)
From n7oo@hereford.ampr.org Thu Jun 15 12:45:55 1995
Received: from usacec-osigw.army.mil (usacec-osigw.army.mil [137.80.1.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA09383 for <hfsig@tapr.org>; Thu, 15 Jun 1995 12:45:42 -0500
Message-Id: <199506151745.MAA09383@dingus.n5lyt.datarace.com>
Received: from slip1.cec.army.mil by usacec-osigw.army.mil id aa00430;
          15 Jun 95 17:19 MST
X-Sender: jtaylor@usacec-osigw.army.mil
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Jun 1995 10:41:18 -0700
To: hfsig@tapr.org
From: Jack Taylor <n7oo@hereford.ampr.org>
Subject: New Clover board

Page 177 of the June 95 QST has an announcement from HAL on their new $395
DSP modem, the P38.  Understand this uses one of the TI chips and comes with
software for clover, pactor, amtor, baudot and ascii.  If packet could be
ported to it, one would have a near ideal modem!

73 de Jack

From gjones@tenet.edu Thu Jun 15 13:06:55 1995
Received: from beall.tenet.edu (Nadine-Ruth-Beall.tenet.edu [198.213.2.11]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA09579 for <hfsig@tapr.org>; Thu, 15 Jun 1995 13:06:50 -0500
Received: (from gjones@localhost) by beall.tenet.edu (8.6.11/8.6.9) id NAA06308 for hfsig@tapr.org; Thu, 15 Jun 1995 13:06:47 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199506151806.NAA06308@beall.tenet.edu>
Subject: Re: [HFSIG:402] New Clover board
To: hfsig@tapr.org
Date: Thu, 15 Jun 1995 13:06:47 -0500 (CDT)
In-Reply-To: <199506151745.MAA09383@dingus.n5lyt.datarace.com> from "Jack Taylor" at Jun 15, 95 01:02:15 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 748       

Very similar to the DSP-93 except that it has a 68000 processor on it and is
a plug in card.

So - to port code you have to program the 68000 and TI chip.  Makes it much
more fun.

Bill Henry intro the unit at Dayton.  Interesting unit.
You can think of it as a scaled down clover board.

I think Bill or someone from HAL is on the mail list - they could probably
go into it in a lot more detail.

Cheers - Greg

According to Jack Taylor:
> 
> Page 177 of the June 95 QST has an announcement from HAL on their new $395
> DSP modem, the P38.  Understand this uses one of the TI chips and comes with
> software for clover, pactor, amtor, baudot and ascii.  If packet could be
> ported to it, one would have a near ideal modem!
> 
> 73 de Jack
> 
> 

From mcdermot@eagle.aud.alcatel.com Thu Jun 15 13:56:44 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAA10072 for <hfsig@tapr.org>; Thu, 15 Jun 1995 13:56:41 -0500
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA11600; Thu, 15 Jun 95 13:56:39 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA02000; Thu, 15 Jun 95 13:56:38 CDT
Date: Thu, 15 Jun 95 13:56:38 CDT
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9506151856.AA02000@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:402] New Clover board

> From hfsig@tapr.org Thu Jun 15 13:16:07 1995
> Reply-To: hfsig@tapr.org
> Page 177 of the June 95 QST has an announcement from HAL on their new $395
> DSP modem, the P38.  Understand this uses one of the TI chips and comes with
> software for clover, pactor, amtor, baudot and ascii.  If packet could be
> ported to it, one would have a near ideal modem!
>
> 73 de Jack
>
>

	I talked with Bill Henry for a few minutes at Hamcom about the P38
	board,
he said that the 320C25 runs at 50 Mhz., and it uses the 68360 Motorola
processor.
The 68360 has a 68020 core, and has several HDCL and other serial channels
built
in, plus DMA controllers -- the 68360 is a very powerful chip (we use them at
work).
The HAL P38 board will not work at the two highest speeds of CLOVER II.  The
T.I.
chip does not have the capability of the Motorola 56000 that is used on the
original
CLOVER board.  Many of the tricks in the 56000 are what made Clover run
fast..

							- Tom, N5EG

------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------
From elvey@hal.com Thu Jun 15 15:30:10 1995
Received: from hal.com (hal.COM [192.88.244.33]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id PAA10663 for <hfsig@tapr.org>; Thu, 15 Jun 1995 15:30:05 -0500
Received: from civic.hal.com by hal.com (4.1/SMI-4.1.1)
	id AA21815; Thu, 15 Jun 95 13:30:03 PDT
Received: by civic.hal.com (4.1/SMI-4.1.2)
	id AA07941; Thu, 15 Jun 95 13:29:53 PDT
From: elvey@hal.com (Dwight Elvey)
Message-Id: <9506152029.AA07941@civic.hal.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:403] Re: New Clover board
Date: Thu, 15 Jun 1995 13:29:53 -0700 (PDT)
Mime-Version: 1.0
X-Mailer: Ishmail 1.0.4-sun-950116
	Available via anonymous ftp from ftp.halsoft.com

Greg Jones <gjones@tenet.edu> wrote:
> 
> I think Bill or someone from HAL is on the mail list - they could probably
> go into it in a lot more detail.
> 
> Cheers - Greg

Hi All
 I hope I'm not the one that Greg is refering to. I work for HaL Computer
Systems. Other then our software company in Austin we are making a high
end work station. No modems 8-)

 I'm not sure if I posted this stuff before but I have done some stuff
that might be of interrest. I have used a DigiCom Systems modem, called
the Connection 14.4+ SoftModem, as my development platform. The board
has a MAFE that is primarily used for phone modems. Normally the MAFE
has a phase lock loop that syncs to the various baud rates. It also
has the ability to do various asyncronous sample rates up to 38.8K.
This is the way I use it. The board has either a 2115 or a 2101 on
it depending on the model and it has a full complement of loadable
RAM in the program and data memory ( 14Kx24 & 14Kx16 ). These boards
are still sold by a few people at about $60 to $80 each or one could
get them used for about $35. I have written some tools for these,
including a binary loader, that are available from ftp 
taygeta.oc.nps.navy.mil under /pub/Forth/Reviewed/DSP/ as dspkit.zip
and hfrfax.zip. The hfrfax was a radio fax demodulator that I made
using this platform. The assembler that I used for this was one of my own
invention and may not be to all's liking.
 I also have one of the ADI's EZKIT Lites that I have written a DOS
loader and uploader for. These are available from ftp  ftp.analog.com
under /pub/ as ezup1.zip and ezld1.zip. I intend to make a translator
to change the ADI's *.EXE format into a format that can be loaded into
the Connection board. This will allow one to work in the assembler
that came with the EZKIT to write code to work on the Connection board.
Only thing that one would have to watchout for would be not to use
the few instructions that are only on the 2181 that comes with the kit.
Dwight

From chbrain@dircon.co.uk Thu Jun 15 16:31:39 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA11153 for <hfsig@tapr.org>; Thu, 15 Jun 1995 16:31:24 -0500
Received: by felix.dircon.co.uk id AA19041
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 15 Jun 1995 22:29:05 +0100
Message-Id: <199506152129.AA19041@felix.dircon.co.uk>
Received: from ad048.pool.dircon.co.uk(193.128.231.48) by amnesiac via smap (V1.3)
	id sma019031; Thu Jun 15 22:28:52 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Jun 1995 20:42:45 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:401] Re: some questions

>Dear Ilkka,
>
>To be honest, I don't really know what "NVIS" means - can anyone help?
>
 It stands for Near Vertical Incidence Skywave and means the signal goes 
almost vertically up. The idea is to cut out the skip zone for tactical H.F
communications rather than for strategic systems. It's all the thing in military
circles at the moment.


Regards Charles G4GUO.
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From ALAN_BLOOM@HP5300.desk.hp.com Thu Jun 15 17:43:49 1995
Received: from hp.com (hp.com [15.255.152.4]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id RAA11840 for <hfsig@tapr.org>; Thu, 15 Jun 1995 17:43:41 -0500
From: ALAN_BLOOM@HP5300.desk.hp.com
Received: from opnmail3.corp.hp.com by hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.3) id AA089266215; Thu, 15 Jun 1995 15:43:35 -0700
Received: from  by opnmail3.corp.hp.com with SMTP
	(1.37.109.8/15.5+ECS 3.4 Openmail) id AA27530; Thu, 15 Jun 1995 15:42:38 -0700
X-Openmail-Hops: 2
Date: Thu, 15 Jun 95 15:40:00 -0700
Message-Id: <"d0f,IAR000000000*"@MHS>
In-Reply-To: <"27F55CE0C08(l)a(*"@MHS>
Subject: [HFSIG:401] Re: some questions
To: hfsig@tapr.org

>To be honest, I don't really know what "NVIS" means - can anyone help?

"Near-Vertical Incident Skywave"  -- It means a short-distance path
(that would normally be covered by groundwave) that instead uses
ionospheric reflection.  There's been a lot of hype recently about
"NVIS antennas" which are just antennas designed to minimize
ground wave (low-angle) radiation.  (i.e. the opposite of what
you want for long-distance communication.)  The advantage is that
for short paths you get less fading, because there is no ground wave
path to destructively interfere with the skywave.

AL N1AL
From sid@xm.doe.ernet.in Fri Jun 16 03:55:29 1995
Received: from sangam.ncst.ernet.in (sangam.ncst.ernet.in [144.16.11.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id DAA17112 for <hfsig@tapr.org>; Fri, 16 Jun 1995 03:55:21 -0500
Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.12/8.6.6) with UUCP id OAA18357 for hfsig@tapr.org; Fri, 16 Jun 1995 14:25:53 +0530
Received: from doexm.UUCP by doe.ernet.in (4.1/SMI-4.1-MHS-7.0)
	id AA23548; Fri, 16 Jun 95 14:24:09+050
Date:     15 Jun 95 10:02:14 IST (+0530)
From: Siddharth Bhatachara <sid@xm.doe.ernet.in>
To: hfsig@tapr.org
Subject: Help.
Message-Id: <A.805216833@xm.doe.ernet.in>
X-Mail-Ref: 128
X-Mailer: XMAIL 3.0
Request-Delivery-Notification: true


I have just become a subscriber of this wonderful mailing
group and I find a lot of interesting things happening here.

This is my first posting to the list. I need info on the
following :

1. The german pactor level-II  modem PTC-II's availability.
Whether the modem can be purchased in kit form or whether
any documentation on its design is available.

2. The PC-PACTOR software to operate Pactor with the AN-93
modem which I intend to build. I could locate the PCTOR
and download it from the tapr ftp site. Please let me know
where from I can get the PC-PACTOR.

Thanks and cuagn later.

-------------------------------------------------------------------
Siddhartha Bhattacharjee       Internet : sid@mahavir.doe.ernet.in
Senior Scientific Officer,     Amateur Packet Radio :
MAEP, C & I Division,                   vu2sid@vu2dpg.del.ind.as
Room No. 3091,Department of Electronics,
C.G.O. Complex, New Delhi      Phone : 4363102 Ext.3491/4363112
-------------------------------------------------------------------

From 72253.2602@compuserve.com Fri Jun 16 08:46:15 1995
Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [198.4.7.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA19201 for <hfsig@tapr.org>; Fri, 16 Jun 1995 08:46:10 -0500
Received: by arl-img-2.compuserve.com (8.6.10/5.950515)
	id JAA18845; Fri, 16 Jun 1995 09:46:06 -0400
Date: 16 Jun 95 09:44:16 EDT
From: Peter Schulze <72253.2602@compuserve.com>
To: TAPR-HFSIG <hfsig@tapr.org>
Subject: Re: Help
Message-ID: <950616134416_72253.2602_EHJ113-5@CompuServe.COM>

Hi everybody,

In reply to Siddhartha Bhattacharjees questions the following articles
about Pactor-2 maybe of general interest. These articles were first
published by the ADRS Digital Journal. All rights belong to ADRS (now
IDRA). IDRA agreed to the posting of these three articles on the Internet. 

As the articles are rather long i will send them in three different
messages. 

The PTC-2 modems are avaible from SCS in Germany. 

SCS 
Rontgenstrasse 36
63454 Hanau
Tel/Fax: +49 6181 23368

price is in the 1000$ range. 

At the Dayton Hamfest, Paccom and AEA anounced Pactor2 controllers
for later this year. 

I do not have a pactor 2 modem, so i can't make any comments about the
performance. Does anybody have experience with these units ??

73
Peter Schulze TY1PS

P.S.
i pulled this out of the S92ZM mbo yesterday:
TY1PS de S92ZM>
Nr: 4469  To: PACTOR  From: 7Z1AB
p

Ptc II QRV list 16/6/95
R:950615/1334z @:OE4XBU.AUT.EU [WINLINK AUSTRIA] #:14091
R:950616/1027z @:7Z1AB.#APL.SAU.AS [USEARS-Desert-Network-Pct-I&II]
#:3617
R:950616/1025z @:7Z1AB.#KAM.SAU.AS [USEARS-Desert-Network-Gtor-PORT]#:312

        UUUUUUU" UUUUUUU"  UU"  UUUUU"  UUUUUU"
        EIIIIUUo EIIUUUE? UUUo UUEIIUU" UUEIIUU"
            UUE?   UUUE?  EUUo UUUUUUUo UUUUUUE?
           UUE?   UUUE?    UUo UUEIIUUo UUEIIUU"
           UUo   UUUUUUU"  UUo UUo  UUo UUUUUUE?
           EI?   EIIIIII?  EI? EI?  EI? EIIIII?
       UNITED STATES EMBASSY AMATEUR RADIO SOCIETY
     UAAAAAA? UAAA? U UA? UAAAAAA? UAAAAAA? UA? UA?
     3 UAA? 3 A? UU 3 3 3 3 3 UAA? 3 A? UA? 3 3 3 3 3
     3 AAAU 3  3 3  3 AAU 3 3 AAAU 3  3 3 3 3 3 AAU 3
     3 UA? UU  3 3  AA? UAU 3 UAA? 3  3 3 3 3 3 UA? 3
     3 3 3 A? UU A?   3 3   3 3  3 3 UU AAU 3 3 3 3 3
     AAU AAAU AAAAU   AAU   AAU  AAU AAAAAAAU AAU AAU
   22222222222222222222222222222222222222222222222222222

       This Stations are QRV in PACTOR Level I & II
===================================================================
* Call * Amtor *  Name  * QRG-Mark *         QTH/Remarks
*
===================================================================
7Z1AB    ZZAB    Rudolf    14.080   USEARS (PctII=7Z1AB-L2) 2MB-BBS

DF7ML    DFML    Alf                Muenchen
DK2YF    DKYF    Willi     14.090   Nuernberg
DK5FH    DKFH    Armin      3.583.25 Maintal
DK5FJ    DKFJ    Gerd               Wiesbaden
DK7HN    DKHN    Juergen            Spaichingen
DK8NZ    DKNZ    Richard            Hersbruck
DK9NQ    DKNQ    Walter             Lindlar
DL1AN    DLAN    Hans       7.039   Hofheim
DL7LD    DLLD    Achim              Berlin
DL1FAN   DFAN    Guenther   3.593 7.039 14.082 Frankfurt/Main
DL1FDJ   DFDJ    Karl      14.076    \MM Flying Germania II
DL1GWX   DGWX    Charly    14.079  3.575 Sigmaringen
DL1ZAM   DZAM    Martin     3.583.25 Maintal
DL1ZAV   DZAV    Rudolf    14.072.5  Karben or Bangkok/HS 2MB-BBS
DL2FAK   DFAK    Tom       14.079 3.583.25 Hanau
DL2GRF   DGRF    Frank     14.079   Offenburg
DMEN   DMEN    Ingo               Oberstaufen

DL3MFH   DMFH    Gerd               Muenchen
DL3RCF   DRCF    Christian 14.076   Poppenricht
DL4BCA   DBCA    Reinhard           Bremen
DL5YDJ   DYDJ    Joachim            Boffzen
DL6MAA   DMAA    Peter              Mindelheim
DJ7PO    DJPO    Joerg     14.079   Offenburg
DJ9VB    DJVB    Rolf      14.060.8 Oberhausen
DJ0JV    DJJV    Nussi              Muenchen
DJ0OW    DJOW    Roy       14.079   Offenburg
EA5FIN   EFIN    Arthur     7.039 14.072/74/76.5 La Manga  (PA0LAM)
EA5XK    EAXK    Herbert            Moraira                 (DL1VR)
HB9NP    HBNP    Fred               Mutschellen
HB9BDM   HBDM    Chris              Umiken
HB9BIQ   HBIQ    Tad                Nierderwil
HB9COK   HCOK    Alfred     3.579 14.060 Mutschellen    (on weekends)
HB9EBW   HEBW    Werner             Ruenenberg
HB9LAR   HLAR    Chris
JK1DNW   JDNW    Jo                 Nagoya/JA
KB6BT    KBBT    Walter     14.073/78/79 21.073 California
KB8LUJ   KLUJ    Phil        3.642 14.079 Ohio
KR8R     KKRR    Gerhard     3.642 14.090 Ohio
OE9ERI   OERI    Helmut      3.583.25 Rieslern
VE3BGE   VBGE    Mike       14.077/79 Toronto         13/14:00
Utc
VK6BCP   VBCP    Walter               Perth
W1BEL    WBEL    Gwyn                 Tampa/FL
W9UWE    WUWE    Julius      7.035.6/79 14.073/79/85 21.079 Chicago

WA2MFY   WMFY    Pete          (any SYS/2 frequency) New Jersey
XE1HOS   XHOS    Henry                Mexico


        Who is the next on this list...YOU ??

 If you know some more Call's send update Info to SysOp 7Z1AB

   tnxs 73 de Rudolf HS0/DL1ZAV SysOp @7Z1AB.#APL.SAU.AS
TY1PS de S92ZM>

From 72253.2602@compuserve.com Fri Jun 16 08:46:15 1995
Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [198.4.7.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA19202 for <hfsig@tapr.org>; Fri, 16 Jun 1995 08:46:10 -0500
Received: by arl-img-2.compuserve.com (8.6.10/5.950515)
	id JAA18849; Fri, 16 Jun 1995 09:46:07 -0400
Date: 16 Jun 95 09:44:27 EDT
From: Peter Schulze <72253.2602@compuserve.com>
To: TAPR-HFSIG <hfsig@tapr.org>
Subject: [HFSIG:404] Re: New Clover board
Message-ID: <950616134426_72253.2602_EHJ113-6@CompuServe.COM>

Hi everybody,
Bill Henry gave me one of the new P38 boards in order to make sure that my
Express software
works ok on it. The board runs well and caused no problems so far. I will post
the technical
specs tomorrow as i don't have them at hands now here. Amazingly my board does
the two
fast modes that apply amplitude modulation. Maybe i have an early board, and
they cut that off later for commercial reasons. But this shows that the DSP is
fast enough for that. 
more tomorrow...

73 Peter TY1PS
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                                PACTOR-II

             The new Dimension in Data Transmission Technology

          By Dr. Tom Rink, DL2FAK, and Hans-Peter Helfert, DL6MAA

            Part 3: Short Description of the PACTOR-II Protocol


I. Introduction

All new modes should provide significant improvements over existing systems,
which must not only refer to the maximum throughput and the robustness. Other
basic attributes, like signal bandwidth, required frequency accuracy and com-
patibility to existing standards also have to be taken into consideration.

Modulation and encoding methods that supply high throughput rates, e.g. 16-
DPSK, normally suffer from a lack of robustness. On the other hand, systems
distinguished by a high robustness, e.g. DBPSK combined with a rate 1/2 con-
volutional code, only provide a low maximum throughput. Therefore adaptive
digital modes have to be used, that apply different modulation and encoding
methods depending on the channel quality. Just changing the symbol rate how-
ever, leads to only little adaptivity and additionally results in variations
of the bandwidth. In order to prevent any spillover in adjacent channels, the
bandwidth should ideally always remain the same, regardless of whether a ro-
bust or a fast data transmission is performed. As 500 Hz CW filters are very
commonly used and due to the usual spacing of the mailbox frequencies on short
wave, a maximum bandwidth of 500 Hz should not be exceeded. In addition, there
should not be too high a demand placed on the transceiver used, regarding its
frequency adjustment and stability. For optimum results, maximum frequency de-
viations similar to FSK modes should be tolerated. This forces the use of po-
werful tracking methods, which allow a link also to be established if the de-
viation is up to +/- 80 Hz. Further, a new mode should be backwards compatible
to an existing standard, preferably with automatic switching, in order to pre-
vent a deficiency of QSO partners in the early stage.
PACTOR-II meets all the above mentioned requirements. It is fully backwards
compatible with the current PACTOR standard, as the initial link setup is still
done in FSK. If both stations are capable of Level II, an automatic switching
is performed. The PACTOR-II protocol basically uses a two-tone DPSK system with
raised cosine pulse shaping, which reduces the required bandwidth to less than
500 Hz. The maximum absolute transfer rate is 800 bits per second. Due to the
improved on-line data compression, maximum effective throughput rates of more
than 1200 bits per second can be obtained. PACTOR-II is thus the fastest short
wave digital mode. Very efficient error control coding using a convolutional
code with a constraint length of 9 and a real Viterbi decoder with soft deci-
sion is applied at all speed levels, in addition to analog Memory-ARQ. PAC-
TOR-II is also therefore, by far the most robust digital mode, which allows a
link to be established and achieve a reasonable throughput in such poor propa-
gation conditions that all other modes fail. In comparison with the current FSK
PACTOR standard including analog Memory-ARQ, which had been the most robust
digital mode until the release of PACTOR-II, a further gain of robustness of
around 7 dB could be obtained. The following chapters describe some details of
the PACTOR-II protocol.

II. Structure and Timing of the PACTOR-II Frames

Similar to the current FSK PACTOR standard, PACTOR-II is also a half-duplex
synchronous ARQ system without any mark/space convention. It may thus be oper-
ated in USB as well as LSB position of the transceiver. The initial link setup
is still performed using the FSK (PACTOR-I) protocol, in order to achieve com-
patibility to the previous level. If both stations are capable of PACTOR-II,
an automatic switching to the higher level is performed. The basic PACTOR-II
frame structure is similar to PACTOR-I. It consists of a header, a variable
data field, the status byte and the CRC. The standard cycle duration does not
differ from FSK PACTOR and is still 1.25 seconds, which is one of the require-
ments to obtain easy compatibility to Level I. Longer Control Signals (CS) had
to be applied to achieve a higher robustness for the acknowledgment signal,
required due to the greater robustness of the data channel. The entire length
of the standard packet had to be shortened to 0.8 seconds in order not to
shorten the maximum possible propagation delay, which is thus still 170 milli-
seconds. The requirements to operate PACTOR-II regarding the transmit delay
and the receiver recovery time of the used equipment therefore remain unchanged
in comparison with Level I.

Due to the signal propagation delay, and equipment switching delays, PACTOR-II
as well as PACTOR-I has in the standard mode a maximum range for ARQ contacts
of around 20,000 km. As with PACTOR-I, a long path option is available also for
PACTOR-II, enabling contacts up to 40,000 km. The sending station calls the
partner station in 'Long Path Mode'. Initial contact is established using the
PACTOR-I FSK protocol as previously mentioned, but with a cycle time of 1.4
seconds instead of 1.25. This longer cycle time allows for the much greater
propagation delays found on 'Long Path' contacts. The link then automatically
switches to PACTOR-II, with the same cycle duration. In the new data mode (see
below), timing is also automatically adjusted to obtain longer receiving gaps.

Unlike the previous level, PACTOR-II additionally switches to longer packets
if the data blocks are not filled up with idles, (i.e. if the transmitter buf-
fer indicates that more information has to be transferred than fitting into
the standard packets). If the information sending station (ISS) prefers to use
long packets, it sets the long cycle flag in the status word. The information
receiving station (IRS) then finally can accept the proposed change of the cy-
cle duration by sending a CS6. This situation, for example, occurs when reading
longer files out of mailboxes. The long packets are basically made up like the
short ones, but consist of a larger data field, which may contain up to 2208
bits of usable information. The length of these data packets is 3.28 seconds,
which leads to an entire cycle duration of 3.75 seconds in this so-called data
mode.

When entering text manually in QSO traffic from operator to operator, the maxi-
mum throughput of the standard mode is normally not used up, thus the required
higher flexibility of the system is still available due to the short packets.
The efficient use of longer data packets on short wave is generally only pos-
sible, if powerful error control coding, with full frame interleaving is ap-
plied to cancel out error bursts or short fading periods. As already mentioned,
PACTOR-II uses a convolutional code with a constraint length of 9, a real Vi-
terbi decoder and soft decision, in addition to analog Memory-ARQ. Due to the
high coding gain and the resulting capacity of error correction without re-
questing a repetition of the entire packet, a significant increase in the ef-
fective throughput could be obtained. Proceeding from average bit error rates
on short wave channels, simple block codes are usually unable to provide enough
coding gain. This often leads to a decrease in speed when using longer data
strings, as repetitions often cannot be avoided. For more details on these tech-
nical foundations, see the first part of this series.

PACTOR-II uses six different CS, each consisting of 40 bits, all having exactly
the maximum possible mutual hamming distance of 24 bits to each other. They
thus reach exactly the Plotkin boundary and also represent a perfect code. This
allows the advantageous use of the Cross Correlation method for decoding, which
is also a kind of soft decision, leading to the correct detection of even in-
audible CS. This checking is not only confined to a simple binary principle. A
complex analog test procedure is applied, using the fine detail data from the
DSP, to evaluate the single CS received, as well as the information summed up
in the Memory-ARQ buffer. Similar to Level I, CS1 and CS2 are used to acknow-
ledge/request packets and CS3 forces a break-in. CS4 and CS5 handle the speed
changes, and CS6 is a toggle for the packet length. All CS are always sent in
DBPSK in order to obtain a maximum of robustness.

III. Speed Levels and Error Control Coding 

As mentioned in the introduction, PACTOR-II uses a two-tone DPSK modulation
system. Due to the raised cosine pulse shaping, the maximum required bandwidth
is only around 450 Hz at minus 50 dB. ASK, which was also tested in the early
stage, provided poorer results in weak conditions compared with a higher DPSK
modulation, as different amplitude levels are more difficult to distinguish in
noisy channels than more phase levels. Additionally, ASK increases the Crest
Factor of the signal. For these reasons, it is not used in the final PACTOR-II
protocol. Basic information on these items can also be found in the first part
of this series.

PACTOR-II uses instead, different DPSK modulation schemes and various code
rates. The Crest Factor of the PACTOR-II signal is therefore only 1.45. The
basic code used is an optimum rate 1/2 convolutional code with a constraint
length of 9. Codes with higher rates, e.g. rate 2/3 and rate 7/8, can be de-
rived from that code by so-called puncturing. Prior to the transmission, cer-
tain of the symbols of the rate 1/2 encoded stream are 'punctured' or deleted,
and not transmitted. At the receiving end, the punctured encoded bits are re-
placed with 'null' symbols prior to decoding with the rate 1/2 decoder. The
decoder treats these null symbols neither as a received '1' nor as '0', but as
an exactly intermediate value. No information is thus conveyed by that symbol
that may influence the decoding process. The coding performance of 'punctured'
code operation nearly matches the coding performance of the best known classic
rate 2/3 or 7/8 codes with a comparable constraint length, provided that the
puncture pattern is chosen carefully. The major advantage of this approach is
that a single code rate decoder (in our case a rate 1/2 decoder) can implement
a wide range of codes.
In the PTC-II, the Viterbi algorithm is implemented for decoding of the con-
volutional code. Nevertheless, as already indicated in the first part, there
are several different methods to decode the PACTOR-II signal, which require
less processing power, but in return for this, also provide less coding gain.
However, these methods at least allow compatibility to the PACTOR-II standard
and may therefore be applied in cheaper hardware. 

The most robust PACTOR-II speed level employs DBPSK with rate 1/2 coding, which
per cycle allows an absolute throughput of 5 bytes in the standard mode and 36
bytes in the data mode respectively. In the next step, DQPSK with rate 1/2 co-
ding is applied, which leads to an absolute throughput of 14 bytes in the
standard mode and 76 bytes in the data mode. This is followed by 8-DPSK with
a rate 2/3 coding, providing a throughput of 32 and 156 bytes per packet, re-
spectively. Finally, in best propagation conditions, PACTOR-II applies 16-DPSK
with a rate 7/8 coding, which allows the maximum throughput of 59 bytes in a
short packet and 276 bytes in the data mode. The mentioned transfer rates are
all net rates referring to 8-bit ASCII, which are calculated after the error
control coding and all other protocol overhead. As data compression is usually
active, these throughput rates must be multiplied by the compression factor.
The effective speed is therefore considerably higher in practice. The speed
levels are automatically chosen by the PTC-II, considering the link statistics
and the actual channel quality, thus no user intervention is required.

IV. On-line Data Compression

Like in the previous FSK PACTOR system, automatic on-line Huffman data compres-
sion is applied. Additionally, PACTOR-II uses run-length encoding and, as a
further novelty, Pseudo-Markov Compression (PMC, see below). Compared to 8-bit
ASCII (plain text) PMC yields a compression factor of around 1.9, which leads
to an effective speed of about 600 bits per second in average propagation con-
ditions in data mode. PACTOR-II is already around 3 times faster than PACTOR-I
and 15 times faster than AMTOR on average channels. However, the maximum effec-
tive speed in good conditions can exceed 1200 bits per second. As the PTC-II
firmware automatically checks, whether PMC, Huffman encoding or the original
ASCII code is the best choice, which depends on the probability of occurrence
of the characters, there is no risk of losing throughput capacity. PACTOR-II
is of course still able to transfer any given binary information, e.g. programs
or picture- and voice files. In these cases the on-line data compression is
automatically switched off.

Ordinary Huffman compression exploits the 'one-dimensional' probability distri-
bution of the characters in plain texts. The more frequently a character oc-
curs, the shorter has to be the Huffman symbol that is assigned to the actual
character. On the other hand, Markov compression can be considered as a 'dou-
ble' Huffman compression, since it not only makes use of the simple probabili-
ty distribution, but of the 'two-dimensional' probability. For each preceding
character, a probability distribution of the very next character can be calcu-
lated. For example, if the actual character is 'e', it is very likely that 'i'
or 's' occurs next, but extremely unlikely that an 'X' follows. The resulting
probability distributions are much sharper than the simple one-dimensional dis-
tribution and thus lead to a considerably better compression. Unfortunately,
there are two drawbacks: Since for each ASCII character a separate coding table
is required, the entire Markov coding table becomes impractically large. Addi-
tionally, the two-dimensional distribution and thus also the achievable com-
pression factor depends much more on the kind of text than the simple character
distribution.
We have therefore chosen a slightly modified approach which we called Pseudo-
Markov Compression, because it can be considered as a hybrid between Markov-
and Huffman encoding. In this variant, the Markov encoding is limited to the
16 most frequent 'preceding' characters. All other characters trigger normal
Huffman compression of the very next character. This reduces the Markov coding
table to a reasonable size and also makes the character probabilities less cri-
tical, since especially the less frequent characters tend to have unstable pro-
bability distributions. Nevertheless, for optimum compression, two different
tables for English and German texts are defined in the PACTOR-II protocol and
automatically chosen by the PTC-II.

V. Some Practical Aspects

Similar to Level I, the tones of the PACTOR-II signal are spaced at 200 Hz.
Their frequency may be defined freely in steps of 1 Hz by software command, as
long as the shift remains 200 Hz. Thus you can easily switch between high- and
low-tones, and also adjust any additionally required tone pair. This allows
the utilizing of narrow CW filters in all transceivers that provide the option
of activating the corresponding filters in the SSB mode.
In the PACTOR-II system, the transferred information is swapped from one chan-
nel (tone) to the other in every cycle. Unlike FSK systems, the link is thus
not blocked when strong narrow band QRM completely overpowers one channel (e.g.
CW or carriers), but only its maximum speed is reduced. Usual FSK systems with
a mark/space convention and without Memory-ARQ have to fail in such cases, be-
cause even if a so-called 'space-only' mode is applied, the strongest signal is
automatically chosen. This always leads to a break-down of the link, as the QRM
is stronger than the useful signal in the proposed case.
PACTOR-II provides a comprehensive Listen-Mode, which is much more robust than
known from PACTOR-I, because just the short header has to be received correct-
ly, then the powerful error control coding can be fully utilized. Burst errors
may be corrected also by monitoring stations and thus virtually do not affect
the performance. The Unproto-Mode in PACTOR-II allows to choose between all the
above mentioned speed and encoding levels. On the receiving side, the correct
mode is detected automatically and therefore needs no user-adjustment. For ex-
ample, a fast and very robust QTC mode can thus be achieved, when a message is
transmitted in the Unproto-Mode using DBPSK with rate 1/2 coding.
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                                 PACTOR-II

             The new Dimension in Data Transmission Technology

        By Dr. Tom Rink, DL2FAK, and Dipl.-Ing. Martin Clas, DL1ZAM

                    Part 2: Description of the PTC-II


I. Introduction

This second part of the PACTOR-II series explains the final version of the
PTC-II hardware. As already indicated in the first part, the DPSK modulation
system makes it mandatory to use a DSP as the interface to the short wave
transceiver. Additionally, the convolutional coding with Viterbi decoder re-
quires very high processing power, more than available in any existing modem
on the Amateur Radio market.
However, the many wishes, ideas and suggestions from the ranks of the Radio
Amateurs, have finally led to the development of an even more complex and
flexible unit than necessary to implement the PACTOR-II system. For example,
it has been the wish of many for a long time, to be able to operate not only
with usual digital HF modes, but also to cover VHF and UHF Packet Radio at
the same time, with one unit. Unlike currently available in existing units,
a comfortable built-in mailbox should allow simultaneous access from all com-
munications channels with the same priority, for example in Packet Radio on
23 cms with 9600 baud and on 70 cms with 1200 baud. Naturally, during this
time no PACTOR or AMTOR connect on HF should be lost or ignored. This forces
the use of a RISC (Reduced Instruction Set) processor for fast processing of
the HDLC Packet protocols. As the majority of modern HF transceivers can be
programmed via a serial interface, another wish that has slowly formed, is to
use this feature for remote control of the transceiver. To set up a mailbox
that scans various frequencies on HF, external computer and software is no
longer required. Additionally, you could utilize your home based PTC-II whilst
on the move, or from a remote location using Packet Radio. Instruct the HF
transceiver to tune to a specific frequency, then to make a connect in PACTOR
to a particular mailbox and read the messages.
These and many more ideas have led to hardware of very high performance. Due
to the use of signal processing, the PTC-II is very flexible, and allows a
great variety of different applications to be implemented. These range far
wider than those written of up to now. Those technically talented users can
make their own programs and modules, which may be loaded via the serial inter-
face into the flash memory of the PTC-II. The possible uses are almost unlimi-
ted, as the PTC-II provides a complete, very high performance development plat-
form for DSP and 68020 applications. From simple external control functions
(e. g. automatically turning the antenna to the connecting station), or audio
processing functions (e. g. super-steep sided FIR filters 400th order for CW,
automatic N-times notch filters, etc.) right up to complex functions, like an
audio spectrum analyser or extra operating modes, whether known or still to be
invented, may be implemented.
The PTC-II comes on the market in February 1995. However, as some of the com-
ponents used, among them the new DSP chip, are still difficult to get and due
to the great demand for the PTC-II, the time of delivery for a unit will ini-
tially be about 6 weeks.

II. The Processor Section

As has been made clear in the introduction, to achieve simultaneous processing
of three communications channels along with the signal coding of PACTOR-II, a
powerful computer is essential. A 32-bit processor system has been designed,
based on the new communications processor 68360 (QUICC) from Motorola. This
processor contains an expanded 32-bit version of the well known 68020 CPU, as
used in many powerful computers, together with four separate programmable se-
rial communications ports, the so-called SCC's, implemented as a RISC proces-
sor. Two of these SCC's serve as the interfaces to the Packet Radio modems.
The third SCC is used as RS-232 interface to the terminal. A buffer chip
MAX207A provides the correct RS-232 voltage levels. The baud rate to the ter-
minal is detected automatically, but can also be determined by software com-
mand. The last remaining SCC serves as interface to the HF transceiver for re-
mote control purposes. Four RAM chips with 8 bits each are required, to cover
the 32 bit wide data bus. These can vary between 4 times 32k x 8 up to 4 times
512k x 8. The PTC-II can therefore have a maximum of 2 MB of static RAM, which
plays a large part in running the mailbox and internal administration as well
as external programs, that may be loaded into the PTC-II in addition to the
operating software. In order to further expand the possible applications, the
PTC-II may also contain additional dynamic RAM in the form of a 72 pin SIMM
module of up to 32 MB. The operating system is to be found in a flash memory
of up to 512k*8. Additionally, it is possible to load programs over the serial
interface from the terminal, which would enable the PTC-II to do a totally
different job, as already mentioned in the introduction. Operating parameters
for the PTC-II that should be resistant even to a deep reset are also stored
in the flash memory. Data in this kind of memory remains stored even when no
voltage is applied, but contrary to an EPROM, it may be electrically erased
and re-written whilst in circuit. That makes it very easy updating the system
or running different programs on the PTC-II. A battery-backed-up real-time
clock and other features of the previous PTC are of course still included.

III. The HF Modem with Signal-Processor

The 50 MHz version of the XC56156 DSP from Motorola forms the interface to the
HF transceiver. As the clock frequency is programmable, it is automatically ad-
justed to suit the work of the moment. For easy tasks, such as FSK, the proces-
sing speed can be reduced, yielding a corresponding saving in energy. The DSP
contains a built-in 16-bit digital to analog converter, with the help of which
the audio output signal to the transceiver is generated, be it simple AFSK or
the complex phase modulation of PACTOR-II. The output amplitude is also pro-
grammable and may be set in the range between 10 and 4000 mV by software com-
mand. The normally required 'Mic Gain' potentiometer is thus missing. It is
also possible for the PTC-II to control the output power of the transceiver,
so that the power to maintain the link may automatically be adjusted to an
optimum value. No more power than needed being used, which not only saves on
the electricity bills, but can considerably extend the life of transmitting
components and additionally causes less interference to other stations.
For the signal input, the DSP uses a Sigma/Delta analog to digital converter
with a 16-bit dynamic range (14 bit effective), which enables the normally
necessary Anti-Aliasing filter to be dispensed with. With the exception of the
decoupling OP-AMP at the input and output of the DSP, no further components in
the signal path are required. The DSP contains some built-in static RAM, which
in the PTC-II, is further expanded with 4 additional, very fast, static RAM's.
The size of this RAM is 64k-words (16 bit) and is not variable. This enables
difficult algorithms, for example 4096 point FFT, to be used. As the DSP has
direct access to the main processor data bus, it does not tie up an SCC. The
exact receive frequency of PACTOR-II is very quickly and reliably adjusted by
software, using a newly-developed tracking method. In addition, the DSP is
able, through pulsing the up/down function (which almost every modern trans-
ceiver has as microphone buttons) to automatically change the tuning for op-
timum results. The up/down keys are simulated by transistors, which pull the
respective connection to ground.

IV. The PTC-II Power Supply

The PTC-II contains two power supply input options. Either it may be supplied
via a special DC input connector, or directly from the HF transceiver via the
connecting cable and socket. The two options are decoupled via diodes and feed
a switching regulator. This has a high efficiency, and generates the 5V supply
for the digital section. The supply voltage can vary between 8 and 20 volts.
The current requirement, due to the use of the switching regulator, is depen-
dant upon the supply voltage and the Packet Radio modems used. The higher the
supply voltage, the lower the current consumption. This reverse proportionality
is due to the fact that the power consumed is a product of voltage and current,
and must be virtually the same before and after the regulator. The efficiency
of the regulator is almost unaffected by the value of the supply voltage. The
power supply input of the PTC-II contains special filtering, so that the
switching harmonics from the regulator cannot reach the outside world. The
operating voltage is internally fused with a 5x20 mm fuse. Of course an extra
fuse is delivered with each unit to prevent problems in countries with dif-
ferent standards.

V. The Display and Indicator Unit

The display and indicator unit is built on a separate circuit board, and sits
at right angles to the main board, connected by soldering pads. It carries a
tuning indicator of 15 LED's, 15 further LED's to display the various operating
parameters and a 10-character 5x5 dot matrix LED display.  Most of the LED's,
including the tuning indicator, are dual colour types, to increase the informa-
tion densitiy and the ease of reading the display. The tuning indicator, for
example, changes from red to green as soon as the tuning is optimum for the
chosen operating mode. The 10-character LED display shows the operating mode
and thus eases the display of any possible future update modes, as the PTC-II
is more than sufficient for modes such as FAX, CLOVER-II, etc. Additionally,
various status information as well as the call of connecting stations is also
given on this display, thus in many cases there will be no need to switch on
a terminal. The display is readable from a distance and from unsuitable view-
ing angles. The brightness is programmable and can be adjusted by a software
command.

VI. The Packet Radio Modems

The ability to operate Packet Radio with the PTC-II is an integral part of the
operating system, and therefore available on all units. The PTC-II is, however,
mainly an HF controller, and thus the Packet Radio modems are implemented as
modules, to be plugged in if the need arises. This enables a certain amount of
mechanical compactness (the entire PTC-II is approximately the size of a modern
VHF mobile transceiver). It also prevents those who only need an HF system from
being forced to pay for an unwanted Packet Radio modem. The PTC-II contains
connectors in the form of double PCB strip headers, on to which the modems can
be easily plugged as required. There is space provided for two modems, which
are automatically sensed when present. Two types of Packet Radio modems will be
offered. A simple and cheaper version using the well-known modem chip TCM3105
for 1200/2400 baud, as well as a version with the XC56156 DSP chip. The DSP
version is able to accomodate all baud rates from 300 to 9600 baud. The switch-
ing is accomplished by a software command. DSP programming and the clock are
supplied from the main board, so that, apart from the DSP chip itself, virtual-
ly no extra components are required for the signal processing. Additionally,
the DSP modem board has space for an EPROM and its own clock generator, as well
as baud rate switching. These enable the modem board also to be used either as
a stand-alone modem, or together with other equipment. It delivers the usual
Packet Radio signals of RxD, RxClock, TxD, TxClock and DCD. It is thus compa-
tible with all other Packet Radio systems. Even the connections to the double
PCB strip header are compatible with the usual Packet Radio system standards.

The Packet Radio boards are not initially available however. They will come on
the market in the middle of 1995, together with the corresponding firmware up-
grade for the PTC-II.

VII. The PTC-II Construction

The PTC-II is made up of two printed boards, a main board of 147x170 mm, and a
front board which, as described above, contains the displays and is mounted at
right angles to the main board. The main board is a 6-level multi-layer con-
struction and contains internal ground and supply voltage areas. On the back
is the DC input connector, an on/off switch, an 8 pin DIN connector for the HF
transceiver, two 5 pin DIN connectors for Packet Radio, an 8 pin Mini-DIN sock-
et for the transceiver control as well as a 9 pin SUB-D socket for the terminal
connector. All DIN plugs are delivered together with the unit. Every single pin
of every socket has its own filter in order to improve the HF rejection in
strong RF fields, as well as to prevent unwanted radiation of electromagnetic
energy. On the front is a row of 52 finger-pads for solder connection with the
front board, a mounting method used on all SCS controllers. The construction is
largely SMD. The flash memory and four static RAM's are socketed to enable easy
system upgrades. The RS-232 interface chip is also in a socket to allow easy
replacement in event of damage. The SIMM module, due to its construction, needs
a holder without which it cannot be mounted. An 8 way DIL switch is also in-
cluded so that various parameters may be set that should not be changed via
software. The whole is enclosed in an aluminium profile case, well known from
previous SCS-PTC's and many TNC's. Both front and rear of the case are silk-
screen printed, at the front using three colours. The green and red lettering
of the dual colour LED's explain their meaning when lighting green or red,
respectively.
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	This article was originally published in the ADRS Digital Journal.

                                  PACTOR-II

               The new Dimension in Data Transmission Technology

            By Dr. Tom Rink, DL2FAK, and Hans-Peter Helfert, DL6MAA

                    Part 1: Basic Technical Information


I. Introduction

PACTOR was designed more than five years ago in Germany, in order to overcome
the known disadvantages of AMTOR and Packet Radio. PACTOR is a cheap and re-
liable means of fast, robust and error-free data transfer over short wave
links, and which does not exceed the usual 500 Hz bandwidth limit for digital
modes.
For the first time, not only the complete ASCII character set, but any given
binary information could be transferred over short wave, even in very poor pro-
pagation conditions. Another aim of the system development was the utilizing of
inexpensive and widespread hardware. Since 8-bit controllers without Digital
Signal Processor chips (DSP's) were state of the art at that time, Frequency
Shift Keying (FSK) had to be chosen as a modulation method. Up to now, PACTOR
with analog Memory-ARQ is still the most robust digital mode used in Amateur
Radio. It is also still the fastest FSK mode that fits into a 500 Hz channel.
These may be some of the reasons that have made PACTOR a standard, which is not
only included in virtually all short wave modems in the Amateur Radio market,
but is also widespread in the commercial world.
In the meantime however, more powerful CPU's and DSP's have been developed.
Processing power that greatly exceeded the financial limits of the average
Radio Amateur a few years ago, has dropped to an acceptable price. Some of the
current high-end modems for short wave operation already include a DSP, and in
a few years you can expect all new modems to contain these chips. The through-
put within a 500 Hz channel, as well as the robustness of a system can still
be dramatically improved, by using modulation methods different to FSK, com-
bined with powerful error control coding algorithms. A new standard that takes
advantage of the forthcoming hardware generation is thus required.
These considerations have led to the development of PACTOR-II. This is not
'another new mode', but a fully backwards compatible improvement to the current
PACTOR protocol, with automatic switching. As there are already several compa-
nies interested in licensing PACTOR-II, the German development group made sure
that an implementation in units different from the original PTC-II will also be
possible. However, using a less powerful hardware means sacrificing at least a
considerable part of the weak signal performance of the system.

This is the first of a series of three parts that describes the PACTOR-II sys-
tem and the ideas behind it. In this first chapter, we will just explain some
important technical fundamentals that everybody has to be aware of, to under-
stand the advantages of the new protocol. The second part describes the PTC-II
hardware. The third part deals with details on the PACTOR-II protocol.

II. Modulation Methods

1. Frequency Shift Keying (FSK)

FSK was the first teletype modulation method used, and is still by far the most
widespread one. The information is encoded using rectangular pulses, represen-
ted by an interleaved ON/OFF keying of two carrier frequencies. The symbol rate
is defined as fraction 1/T, the so-called baud rate. T represents the symbol
duration. In FSK systems, the typical wide spectrum that could be expected when
modulating a rectangular baseband signal on a carrier, is cancelled out by a-
voiding phase discontinuities between successive pulses. Thus only the main
lobes around the two carrier frequencies are dominant. The amplitude of a 200
baud signal at 500 Hz bandwidth is about 30 dB smaller than the amplitude in
the center of the spectrum. If however, the baudrate is increased, the band-
width of the main lobes will naturally also increase. A 300 Baud signal, for
example, clearly exceeds the 500 Hz bandwidth, hence an ordinary CW filter
cannot be applied without distorting the pulses. This greatly deteriorates the
performance and thus also the Bit Error Rate (BER) of the system. Additionally,
signals with higher baud rates suffer from a significant loss of immunity a-
gainst time smearing (see below). For these reasons, 200 baud is commonly con-
sidered to be the maximum useful symbol rate of 2-tone FSK systems, operating
over short wave links. Additionally, with regard to the over-crowded frequen-
cies, all new systems should generally require not just a narrow bandwidth,
but provide an improved spectral efficiency to obtain a higher throughput. We
have therefore to look for a different approach, instead of using FSK.

2. Phase Shift Keying (PSK)

In PSK systems, the phase of a signal is used as a means of the information
transfer. However, as the HF propagation conditions sometimes change quite
rapidly, it is very difficult to track the absolute phase of a signal. There-
fore it has proven to be much more efficient to utilize the phase difference
between successive pulses. This requires a slightly higher Signal to Noise
Ratio (SNR), but in return, the resistance against multipath effects is drama-
tically increased. Modulation that employs phase differences between succes-
sive pulses to encode the information is called Differential Phase Shift Key-
ing (DPSK). If there are only two possible phase differences, signalling logi-
cal one and zero, the modulation is called Differential Binary Phase Shift
Keying (DBPSK). If there are four possible phase differences, signalling logi-
cal dibits, it is called Differential Quadrature Phase Shift Keying (DQPSK).
For example, with an one-tone 100 baud DQPSK signal, 200 bit/sec. can be trans-
ferred. If more phase differences are distinguished, the corresponding systems
are called 8-DPSK, 16-DPSK, etc.
As phase shift keying naturally implies phase discontinuities between succes-
sive pulses, the spectrum of a DPSK system with hard keying shows the typical
strong side-lobes of a rectangular pulse spectrum. The amplitude of a hard-
keyed 100 baud DPSK signal is only around 15 dB smaller at a cut-off frequency
of +/- 250Hz than in the center of the spectrum. Thus hard keying must not be
used on short wave due to the resulting large bandwidth. To avoid this problem,
the baseband signal of a PSK system must be specifically prepared before it
gets as far as being modulated on the carrier. This is done by transforming the
rectangular pulses containing the binary information into suitable wave forms,
using special shaping algorithms. H. Nyquist has designed a pulse with very
useful properties, the so-called raised-cosine pulse, which does not produce
any spectral spillover. These pulses do not produce any intersymbol interfer-
ence either, since their amplitude is zero at the sampling time of successive
pulses. Thus they can be overlapped without any interference between them, even
if the pulses are four times longer than the corresponding rectangular pulses.
This is the reason why a very high information density and a good spectral ef-
ficiency can be obtained using raised-cosine pulses. Since a raised-cosine DPSK
signal with a symbol rate of 100 baud only occupies a bandwidth of around 200Hz
at -45 dB, it is obvious that two of these signals can be placed together into
a 500Hz channel. The resulting system is called two-tone-DPSK. It can robustly
transfer 400 bit/sec. within a bandwidth of less than 500Hz, if DQPSK is ap-
plied or up to 600 bit/sec. within the same bandwidth using 8-DPSK.

III. Robustness

The simplest test of the robustness of a modulation system is the measurement
of its behaviour in presence of Arbitrary White Gaussian Noise (AWGN). DQPSK is
known to be more rubust than FSK, though it also has a better spectral effi-
ciency. For example, to obtain a BER of 10E-4, the required SNR per bit is
10.7dB when using DQPSK, but 12.3dB when using FSK. DBPSK requires an even
smaller SNR of 9.3dB in that case, and is thus the most robust mode mentioned.
It is also important to remember that signals with many levels, e. g. 16-DPSK,
require more energy per bit than DBPSK or DQPSK. Generally, a compromise has
to be found between the symbol duration (i. e. the baud rate) and the number
of bits that each symbol has to carry. Short symbols do require a greater band-
width, but a high throughput can be achieved with only a few levels per symbol.
As a result, the signal is more robust against AWGN than a system with the same
throughput using longer symbols and more levels. On the other hand, short sym-
bols are very susceptible to time smearing (see below) and require a higher
bandwidth. DQPSK with 100 baud has proven to be a very good compromise between
robustness against AWGN and time dispersion, especially if it is combined with
powerful error control coding.

Another very important point for a short wave communications system is the
restistance against multipath effects, which occur if there is more than one
path between transmitter and receiver. Due to the various delays at the re-
ceiving end, the combination of the different received signals does not result
in a copy of the original signal, but in a more or less distorted wave form.
Three major multipath effects can be distinguished: time dispersion or 'time
smearing', frequency dispersion and selective fading. These three effects are
closely related to each other. They are strong if the frequency used is much
below the maximum usable frequency, and if the distance is long. A single hop
path on the 20m band, for example, normally does not suffer from severe multi-
path effects. However, a DX link on the 80m band at night often provides con-
siderably strong multipath problems.
The short term time jitter has a magnitude of up to 5 msec. Larger time smea-
ring can only be observed under very special conditions of the ionosphere. A
baud rate of 100 symbols per second has proven to be low enough for almost all
possible propagation conditions, especially if powerful error control coding
is applied.
Frequency dispersion means that the frequency of the original signal is shifted
on the path between transmitter and receiver. It is the same effect as the so-
called Doppler shift, which can be observed on signals from low orbit satel-
lites. The magnitude of the Doppler shift on normal short wave paths is only a
few Hertz, thus it does not influence ordinary FSK systems. However, the demo-
dulator of a PSK signal needs a very accurate information on the carrier fre-
quency in order to work properly. A DQPSK system with a symbol rate of 100 bit/
sec. can only deliver a correct output, if the frequency error is less than +/-
12.5Hz. Automatic frequency tracking must therefore be applied, which can easi-
ly be done on a DSP. The PACTOR-II signal, for example, can automatically be
tracked by the PTC-II within an offset range of +/- 100 Hz. Longer symbols and
more levels of a DPSK signal require a much higher frequency accuracy. For ex-
ample, a 32 baud 16-DPSK signal, as used in CLOVER-II, needs an accuracy of
better than 1Hz. Thus even small Doppler shifts deteriorate the demodulation
process, because it is not possible to track the frequency fast enough at such
a high accuracy.
Selective fading, the third multipath effect, mainly influences FSK systems,
as the channel with lower SNR determines the BER of the whole system, if the
converter cannot switch to space-only mode. The symmetrical property of a bi-
nary FSK signal is destroyed by selective fading. PSK modulation is quite ro-
bust against this effect.

IV. Intermodulation Products and Crest Factor

Whenever a signal, consisting of two or more parallel carriers or 'tones', has
to pass through a non-linear stage, intermodulation products are generated.
Special attention has to be payed to the third order products, because they are
located relatively close to the original signal components. The final RF power
stage(s) of the average Amateur Radio transmitter, are capable of a third order
intermodulation performance of about -30dB. A two-tone signal with a shift of
200Hz thus produces third order intermodulation products that are located vir-
tually within the original bandwidth of the signal. This means that there will
not be any interference on adjacent channels due to intermodulation effects.
However, a signal consisting of four tones that are spaced at 125Hz, will be
broadened to around 1100Hz of bandwidth at -30dB when passing through the same
stage.

Another item that has to be considered is the Crest Factor, which is defined as
the ratio of maximum signal amplitude to average signal amplitude. Modulation
systems designed for radio frequencies should always have a low Crest Factor,
so that the peaks of the signal wave form do not over-drive the final RF sta-
ges. Among other considerations, the Crest Factor is influenced by the number
of tones used by a system. The more tones that are used, the more difficult it
is to get a low Crest Factor. It is in addition, also influenced by the modula-
tion method. PSK, for example, leads to a lower Crest Factor than Amplitude
Shift Keying (ASK).

V. Error Control Coding

The use of a reliable modulation system is only one of the essential steps
towards the goal of optimum data transmission over the difficult paths encoun-
tered on HF radio. Dramatic improvements can additionally be obtained by cor-
rect preparation of the data before it gets as far as being transmitted by the
modem. To be effective, this process, known as Error Control Coding (ECC), im-
poses very high computing demands on the system processor. Actually the final
limit of achievable transmission reliability depends solely on the processing
power used for the ECC. The more power available, the closer the theoretical
throughput limit, the so-called Shannon Boundary, can be approached.

The basic idea behind this coding is quite simple: A certain number of redun-
dant bits is appended to the original information that has to be transmitted
through a noisy channel. The redundant bits are generated from the original
data by applying special rules, depending on the chosen code. Data and redun-
dancy then form a new string of bits, which is called a code word. The ratio
of the number of information bits and the whole length of the code word is
called code rate. The number of valid code words is obviously less than the
number of possible code words. A good code and the corresponding encoding pro-
cess must produce only those valid code words which have a maximum mutual ham-
ming distance, that means a maximum number of different bits. This maximum mu-
tual distance then allows code words to be recognized and distinguished, even
in the presence of received errors. For example, if the valid code words of a
specific code have a minimum mutual hamming distance of three, each code word
containing a single error can be corrected, as the only valid code word with
the greatest similarity then represents the correct one.

Two main approaches of ECC can be distinguished: block codes and convolutional
codes. Both always require data interleaving to be effective on channels with
burst errors. When applying block codes, the message or packet is devided into
short blocks containing only a few bits. Each short block is then encoded se-
parately and forms a relatively short code word. Popular block codes are the
Golay code, the Hamming codes and the Reed-Solomon code. Block codes can easily
be implemented as they often show a cyclic property and thus do not require
much processing power. However, they have proven to be relatively weak, espe-
cially if the BER is high. They are only able to correct a few errors in each
code word and thus do not provide any benefits in very noisy channels or poor
propagation conditions. Additionally, it is very difficult to utilize soft de-
cision when using block codes. Soft decision means that the decoder does not
only use binary decisions for the error finding process, but also the analog
values provided from the demodulator section. It works similar to the analog
Memory-ARQ of PACTOR and requires an ADC or DSP. 
If convolutional codes are applied, the entire message or packet is encoded
and the resulting code words are longer than the original packet. These codes
are very powerful, and their efficiency is only limited by processing speed.
The complexity of a convolutional code mainly depends on the length of the
tapped shift registers, which work as binary convolver and represent the heart
of the convolutional encoder. This specific number is called constraint length.
It provides an upper boundary of the coding gain that can be achieved by a con-
volutional code. Several methods have been developed for the decoding process
of these codes. The optimum decoder, which allows maximum likelihood decoding,
is called the Viterbi-Decoder. Unfortunately, the relationship between con-
straint length and complexity of a Viterbi-Decoder is not a linear one, but it
increases exponentially. Real-time applications of Viterbi-Decoders were limi-
ted to quite short constraint lengths for a long time due to slow processor
speeds. Nowadays, using the new generation of DSP's, it has become possible to
apply constraint length 9 or even higher convolutional codes. As a major advan-
tage of convolutional codes and the Viterbi-Decoder, soft decision may be im-
plemented and only slightly increases the complexity of the system. PACTOR-II,
as implemented in the original German PTC-II, applies a convolutional code with
contraint length 9 and soft decision.
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To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:408] Help.

Dear Siddhartha and all the recent subscribers,




>
>I have just become a subscriber of this wonderful mailing
>group and I find a lot of interesting things happening here.
>
>This is my first posting to the list. I need info on the
>following :
>
>1. The german pactor level-II  modem PTC-II's availability.
>Whether the modem can be purchased in kit form or whether
>any documentation on its design is available.
>

I think Peter answered that one.


>2. The PC-PACTOR software to operate Pactor with the AN-93
>modem which I intend to build. I could locate the PCTOR
>and download it from the tapr ftp site. Please let me know
>where from I can get the PC-PACTOR.


    PC-PACTOR --
PC-PACTOR for the AN-93 is on ftp.tapr.org /tapr/SIG/hfsig/upload. I have
not really
finished the program (ARQ part is incomplete) as at the time I missed some
crucial details that the Pactor folks (SCS) were reluctant to share.
However, I did get help from someone else that I used to complete the PSA
soundcard version. I will finish the PC-PACTOR version when I get a break.
However, you could certainly use the AN-93 with Tom Sailer's fine program
that will give you all the modes, including Pactor. It is also on the same
ftp site. Let us know how it works for you.

  EXTENDED WELCOME --
It appears that we have a number of new subscribers after Dayton. Welcome to
all of you.

  PACTOR II --
Thanks Peter for the detailed overview of Pactor II. 

I had many gripes about the Pactor I implementation, especially an
inappropiate frame synch method and the inablility for automatic link
re-establishment after failure. I did note, however, that some of these
weaknesses have been addressed in Pactor II. Maybe this is a winner? Hope so. 

Does anyone perhaps know whether the actual protocol for Pactor II is
available? Or do one have to pay the licensing fee to obtain that? 

I think we now have a good idea of the basic modulation scheme, signaling
and ECC, but without the protocol description, experimentor's still cannot
do it themselves as I found that out the hard way when I experimented with
my own version of Pactor I.

 EVM56002 --
I will have the package including the HF modems (works with PC-TOR or HB9JNX
software) by Monday (6/19/95). Look in the hfsig/upload area for it
(EVM56K0.ZIP).
There will be a bit more materials about this project shortly.


73's and keep up the good work.


--Johan, KC7WW  
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According to Johan Forrer:
>     PC-PACTOR --
> PC-PACTOR for the AN-93 is on ftp.tapr.org /tapr/SIG/hfsig/upload. I have
> not really
> finished the program (ARQ part is incomplete) as at the time I missed some
> crucial details that the Pactor folks (SCS) were reluctant to share.
> However, I did get help from someone else that I used to complete the PSA
> soundcard version. I will finish the PC-PACTOR version when I get a break.
> However, you could certainly use the AN-93 with Tom Sailer's fine program
> that will give you all the modes, including Pactor. It is also on the same
> ftp site. Let us know how it works for you.
> 
> 

Good News for all those waiting and already on the list for AN-93 modems.
The volunteer finally finsihed the work and we went to the board shop
Monday with the updated board.  3 weeks for that and then another week or so
to kit and mail.

Letters were mailed to all the people on the AN-93 waiting list eariler this
week.

The updated AN-93 modem support FSK and AFSK output and the new design
allows on-board alignment with a PC program (so no test equipment is 
required).

There will be 100 kits done.  I believe we have taken orders for 35+ to date.

Cheers - Greg, WD5IVD
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Subject: TI DSK and the ISA Bus

Hi all,
 Has anyone got a circuit to interface a TMS320C50 to a PC ISA bus. As you 
know the TI DSK is pretty unusable for real applications due to the method
it talks to the P.C. I was thinking that as all the bus is available on the DSK 
it should be possible to mount it onto a P.C prototype card and communicate
with it using either the DSP parallel ports or via shared memory. Still
using the
serial port for downloads and debuging.  

I am still struggling with my MIL-STD-188-141A 8ary modem, on the DSK
and I have two main problems, the communications described above and
the fact that the TI DSK free assembler is not a macro assembler so it is
difficult
to write properly structured code (well for me)! (or to pinch their example FFT
algorithms!)

On a slightly different tack, the swiss red cross are evaluating pactor II
and are very  impressed with it.
It sounds an ideal platform for an ALE controller, so anyone know how to contact
the german manufacturers? 
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------
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Subject: Re: [HFSIG:401] Re: some questions

>Dear Ilkka,
>
>To be honest, I don't really know what "NVIS" means - can anyone help?
>
>Just for interest sake, you may find it useful to browse the files in
>ftp.tapr.org /tapr/SIG/hfsig/upload
>There are quite a bit on HF propagation; as related to it's affects on
>digital transmissions.
>
>You will also find two Pactor programs there, one that I wrote "PSATOR/PSA-
>PACTOR" for the sound card DSP, and another one by Tom Sailer, HB9JNX, that 
>will work with a number of different types of modems, including something 
>that you can put together on your new EVM56002.
>
>I have ported the Alef Null kernel to the EVM56002 and thus allows you
>to run any of the codes that run on the DSPCARD4. This includes 1200 baud
>BELL 202 and 9600 baud PAM (G3RUH) style modems. The DSP kernel includes 
>all HDLC and KISS interfaces, so all you need to have is the EVM and 
>one of the flavors of NOS/KA9Q on your PC. It's really neat stuff. For the 
>HF side of things, I have some HF modems for the EVM as well. 
>
>Using the ported kernel, you will also be able to participate in the
>experimental high speed HF modem work. There also are a number of 
>excellent noise reduction programs using Wiener, LMS and correltion-
>based algorithms. The latter is by Pawel (SP9VRC) and is a joy to use on 
>CW. 
>
>I am working on putting together the schematic for my version of the EVM's 
>radio interface and will post the complete package (with the kind 
>permission of the Alef Null group) on the net. Watch for the announcement if 
>you are interested.
>
>Think this answers most of your questions. Feel free to e-mail me directly 
>about the EVM56002.
>
>73's
>
>--Johan, KC7WW
>(email: forrerJ@ucs.orst.edu)
>

Hi Johan. Kan nie wag nie....

danie brynard

>
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Subject: EVM56002 program package

Hi all,

I have uploaded evm56k0.zip to ftp.tapr.org /tapr/SIG/hfsig/upload.
We gratefully acknowledge those that gave their kind permission.

Hope you enjoy it.

73's 

--Johan, KC7WW
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Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA15341 for <hfsig@tapr.org>; Mon, 19 Jun 1995 09:52:20 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA20202; Mon, 19 Jun 95 14:52:03 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA803589734; Mon, 19 Jun 95 11:54:42 nst
Date: Mon, 19 Jun 95 11:54:42 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Message-Id: <9505198035.AA803589734@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: pactor 2

     The other day a Posting was made here about Pactor 2 (3parts). Does 
     anyone know the phone number and email address for the company 
     mentioned but not named in the article?
     
     I am extremely interested in getting more info on the PTC-II, 
     including price. Possibly for a commercial application.
     Also I am looking for the availablity and price of the Packet Radio 
     Modules.
     
     Paul Russell
     paulr@neweast.ca
     
     P.S. Its too bad this mailing list eats the address of the mail 
     originator..

From FORRERJ@frl.orst.edu Mon Jun 19 10:28:17 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA15690 for <hfsig@tapr.org>; Mon, 19 Jun 1995 10:28:14 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA07959 for <hfsig@tapr.org>; Mon, 19 Jun 1995 08:27:26 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 19 Jun 95 8:33:50 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Jun 95 8:33:41 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 19 Jun 1995 08:33:31 PST8PDT
Subject:       Re: [HFSIG:416] TI DSK and the ISA Bus
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <2DEF98E2261@frl.orst.edu>

Hi Charles,

I do not know of an easy solution to put that DSK on the ISA bus. You may 
want to consider using one of JDR's ready-made prototyping cards. I have 
used those in the past for building PC-based projects. The cards come in 
either 8-bit or 16-bit flavors and contains all the ISA-bus glue logic. The 
remainder of the cards are then perforated to take wire-wrap parts. The 8-
bit cards costs some $40 price range. The 16-bit cards are a little more 
expensive, but not much. 

The prototyping cards are quite useful - I have built (seems like a long 
time ago) a wire-wrapped dual 68010 co-processor card on one of these cards 
and used a DMA-based host-coprocessor interface.

A bit more along the HF digital lines: let us know how things are 
progressing on the parallel modem - what kind of demodulation filtering 
method are you using?

73's

--Johan
From chbrain@dircon.co.uk Mon Jun 19 14:41:02 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id OAA17843 for <hfsig@tapr.org>; Mon, 19 Jun 1995 14:40:42 -0500
Received: by felix.dircon.co.uk id AA28644
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 19 Jun 1995 20:39:21 +0100
Message-Id: <199506191939.AA28644@felix.dircon.co.uk>
Received: from ad033.pool.dircon.co.uk(193.128.231.33) by amnesiac via smap (V1.3)
	id sma028618; Mon Jun 19 20:38:55 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 Jun 1995 18:52:08 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:420] Re: TI DSK and the ISA Bus


>A bit more along the HF digital lines: let us know how things are 
>progressing on the parallel modem - what kind of demodulation filtering 
>method are you using?
>
>73's
>
>--Johan
>
>
Hi Johan,
 I am working along the lines that Adrian G4ZHZ used in his piccolo modem,
the main problem is implementing an FFT as all the examples I have are done
using macros, I am trying to write a simple macro expander to take the TI
examples and convert them into something the DSK understands. The other
problem is of course the wretched interface to the DSK, I think it will break my
coding skills to implement the modem and expect a software uart to work as
well !!

 I will investigate one of those prototype cards, also they have bought a TI
sun based development system at work with both an assembler and C compiler,
I am negotiating access to it as you read this !!!!

I have been busy with a Linux system as well so that has eaten some of my time
and I am also QRV on H.F from my car now, I have the auto ATU in the trunk and
have a Pro-am 14Mhz vertical on a roof rack that took me ages to ground
properly.

I have also been playing with Phil's KA9Q Viterbi code on my Linux system,
it works great, next thing is to understand what his macros do !

Regards Charles

-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From sid@doe.ernet.in Mon Jun 19 15:03:09 1995
Received: from sangam.ncst.ernet.in (sangam.ncst.ernet.in [144.16.11.1]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA18085 for <hfsig@tapr.org>; Mon, 19 Jun 1995 15:03:01 -0500
Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.12/8.6.6) with UUCP id AAA04596 for hfsig@tapr.org; Tue, 20 Jun 1995 00:23:49 +0530
Received: from mahavir.doe.ernet.in by doe.ernet.in (4.1/SMI-4.1-MHS-7.0)
	id AA18830; Mon, 19 Jun 95 18:17:38+050
Received: by mahavir.doe.ernet.in (4.1/SMI-4.1-MHS-7.0)
	id AA25145; Mon, 19 Jun 95 18:16:53+0530
Date: Mon, 19 Jun 1995 18:16:51 +0530 (GMT+05:30)
From: Siddhartha Bhattacharjee <sid@doe.ernet.in>
Subject: Re: [HFSIG:414] Re: Help.
To: hfsig@tapr.org
In-Reply-To: <9506161705.AA30504@ucs.orst.edu>
Message-Id: <Pine.3.89.9506191855.B24453-0100000@mahavir>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Johan,

I am sorry I could not locate the file PC-PACTOR in the site.
I also could not locate the Tom Sailer's software which
you have referred to in your last mail. 

I would appreciate if you could let me have the details.

The price of the PTC-II is little too much. I understand that
that the sophistication which goes into it is really very
great.  The protocol looks great but it remains to be seen as to 
how does it perform under a given band condition. I was also
very much impressed by the article on G-TOR published in the
May 1994 issue of the QEX. Simplied architecture of the modem
and the price/performance ratio is also required to be looked into
to make it popular among the hams. 

I would request a feedback from one of the PTC-II users ( I do not
know if there is a subscriber of this mailing list ) to say
few words about its performance.

Thanks to all the contributors.

Sid, vu2sid in New Delhi, India.

From FORRERJ@frl.orst.edu Mon Jun 19 15:32:02 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA18435 for <hfsig@tapr.org>; Mon, 19 Jun 1995 15:31:58 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id NAA09715 for <hfsig@tapr.org>; Mon, 19 Jun 1995 13:31:11 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 19 Jun 95 13:37:34 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Jun 95 13:37:24 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 19 Jun 1995 13:37:15 PST8PDT
Subject:       Re: [HFSIG:421] Re: TI DSK and the ISA Bus
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <2E4099210E5@frl.orst.edu>

Hi Charles,

Appears that you are a busy fellow indeed!

Sorry I cannot help much with the C50' macros. Would it be possible to use 
Bison or other parser-generator to do that?

The Linux connection is interesting. I had a go at it about a year ago, but 
gave up after realizing that it was such an incredible moving target. When 
I started following Pawel's work on HF modems, I realized that the whole 
issue of the modem and it's eventual place in a network, needs some thought, 
worthy of exploration. I have had some success with Pawel's modem - BTW, 
the way he does it is to use the Leonid kernel calls to communicate with 
NOS. This way he has a universal software interface. This is a novel idea 
(at least I think so). The version of JNOS that I played with ran 
under DOS, but one must realize that folks that build networks dont use 
DOS any more, anyway you need to keep up with recent software.
Then went on to try OS/2 with very mixed results. I decided to 
remove OS/2 totally from my system after an awful crash (running NOS) that 
destroyed both FAT's on both my hard drives (there were other reasons too). 
I then decided to revisit Linux and been quite amazed by how stable it is. 
The main objective at present is to get a DSP sound card device driver 
functional that will enable one to download DSP algorithms and 
allow development of applications that feeds into Linux's networking 
capabilities. However, as you can imagine, things have gotten quite involved 
now: Not only is it knowing the DSP and programming DSP applications, but 
the Linux device drivers and dealing with TCP/IP as well. 

I welcome further comments, ideas, and suggestions on this theme.

73's

--Johan, KC7WW 












From FORRERJ@frl.orst.edu Mon Jun 19 15:50:47 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA18627 for <hfsig@tapr.org>; Mon, 19 Jun 1995 15:50:43 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id NAA09755 for <hfsig@tapr.org>; Mon, 19 Jun 1995 13:39:36 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 19 Jun 95 13:46:00 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Jun 95 13:45:48 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 19 Jun 1995 13:45:48 PST8PDT
Subject:       Re: [HFSIG:422] Re: Help.
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <2E42D747399@frl.orst.edu>

Dear Siddhartha,

Try the following:

ftp.tapr.org /tapr/software_lib/terminal/PCTOR302.ZIP  ---- PC-TOR 3.02
ftp.tapr.org /tapr/SIG/hfsig/upload/jnx_2.zip   --- HB9JNX software.

You may also find this (and perhaps leater versions) on:

ftp.ucsd.edu /hamradio/packet/tcpip/incoming directory, or in the "DSP"
or "packet" directories. Things move around a bit.

Hope this helps.


--Johan, KC7WW
From chbrain@dircon.co.uk Mon Jun 19 16:38:27 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA19081 for <hfsig@tapr.org>; Mon, 19 Jun 1995 16:38:21 -0500
Received: by felix.dircon.co.uk id AA02968
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 19 Jun 1995 22:39:36 +0100
Message-Id: <199506192139.AA02968@felix.dircon.co.uk>
Received: from ad004.pool.dircon.co.uk(193.128.231.4) by amnesiac via smap (V1.3)
	id sma002954; Mon Jun 19 22:39:24 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 Jun 1995 20:52:35 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:423] Re: TI DSK and the ISA Bus

>Hi Charles,
>
 Not only is it knowing the DSP and programming DSP applications, but 
>the Linux device drivers and dealing with TCP/IP as well. 
>
>I welcome further comments, ideas, and suggestions on this theme.
>
>73's
>
>--Johan, KC7WW 
>
Yes I know exactly what you mean,
 I have been through that route as well, I had OS/2 running on a partition,
I have 
got rid of it now.
 I have two machines one downstairs in the shack, on which  I run DESQview/X
and a second machine upstairs that runs Linux. I use the 'Xterminal' in the
shack
to log into the Linux ssytem over an ethernet, which I am in the process of 
expanding around the house! The people at work think I am nuts.
 
 As far as the macros are concerned, yes they could be done with lex/yacc. Yet
another thing to learn!

 I have started to port all my 'homebrew' software to the Linux environment, its
an ideal Hams OS and it great to have the source, there are a number of 
things I would like to play with like X.400 mail, but I have to concentrate
my efforts
on one thing at a time.


I would like to get some propagation S/W like ioncap to run under Linux. I have
also heard of other Hams using cron tasks to scan radios etc. It seems as if
it would be not too difficult to build a sofisticated system using building
blocks such as Linux.

I am also trying to learn SASD using Cadre Teamwork at work, it would be nice
to get some CASE tools for Linux as well.

Well this ain,t really to do with HFSIG but certainly interesting. Things
seem to be quite quiet here recently.

I must admit I have learn't a lot listening to this sig then reading up
afterwoods,
I have actually found a use for what they tried to teach me at university! I
have
been going through all my basic math books again and also the ones on
modulation etc. Thats what it is all about isn't it.

Regards Charles.


-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From chbrain@dircon.co.uk Mon Jun 19 17:09:39 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id RAA19478 for <hfsig@tapr.org>; Mon, 19 Jun 1995 17:09:31 -0500
Received: by felix.dircon.co.uk id AA03756
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 19 Jun 1995 23:10:45 +0100
Message-Id: <199506192210.AA03756@felix.dircon.co.uk>
Received: from ac042.pool.dircon.co.uk(193.128.230.42) by amnesiac via smap (V1.3)
	id sma003747; Mon Jun 19 23:10:22 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 Jun 1995 21:23:31 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:423] Re: TI DSK and the ISA Bus

Hello again Johan,

Well I have been poking about on ftp.ti.com and have found a file
called 5xdskspc.exe which is a compressed file containing an audio
spectrum analyser for the DSK. Unlike the code shipped with the DSK
which outputs via the D/A port this code talks back via the serial port
and has a graphical display on the P.C. I haven't tried it yet
but it maybe suitable for an FFT and certainly the C++ routines provide
info on how to download code to the DSK from the P.C. I have a look at it
tommorrow.

Regards Charles (off to my bed!)
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From frode@dxcern.cern.ch Tue Jun 20 02:32:23 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id CAA23809 for <hfsig@tapr.org>; Tue, 20 Jun 1995 02:32:19 -0500
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA07486; Tue, 20 Jun 1995 09:32:16 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29089; Tue, 20 Jun 1995 09:32:15 +0200
Date: Tue, 20 Jun 1995 09:32:14 +0200 (MET DST)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Cc: hfsig@tapr.org
Subject: Re: [HFSIG:419] pactor 2
In-Reply-To: <9505198035.AA803589734@ccsmtp.udc.neweast.ca>
Message-Id: <Pine.ULT.3.91.950620092202.27837A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 19 Jun 1995, Paul Russell wrote:

> Date: Mon, 19 Jun 1995 10:06:18 -0500
> From: Paul Russell <paulr@hagar.udc.neweast.ca>
> To: hfsig@tapr.org
> Subject: [HFSIG:419] pactor 2
> 
>      The other day a Posting was made here about Pactor 2 (3parts). Does 
>      anyone know the phone number and email address for the company 
>      mentioned but not named in the article?
>      
>      I am extremely interested in getting more info on the PTC-II, 
>      including price. Possibly for a commercial application.
>      Also I am looking for the availablity and price of the Packet Radio 
>      Modules.
>      
>      Paul Russell
>      paulr@neweast.ca
>      
>      P.S. Its too bad this mailing list eats the address of the mail 
>      originator..
> 

	The company that sells the PTC-II is:

	SCS, Spezielle Communications Systeme GmbH
	Roentgenstrasse 36,
	D-6450 Hanau, Germany.

	Phone/FAX: +49 6181 23368

	This is also the home address of DL2FAK, Dr. Thomas Rink.
 
	73's Frode


	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From JALOCHA@chopin.ifj.edu.pl Thu Jun 22 04:39:01 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA16676 for <hfsig@tapr.org>; Thu, 22 Jun 1995 04:38:45 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id LAA15983 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Thu, 22 Jun 1995 11:08:50 +0200
Date: Thu, 22 Jun 1995 11:08 GMT+1
Subject: Re: [HFSIG:392] HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <190754A320218C58@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

Hello everybody,

Just to report little progress I have just made: I have coded
a 12-tone DQPSK modem into the DSPCARD4.
12 tones, each carries 125 baud, QPSK (4-PSK) => 2 bits/symbol
=> total data rate = 12*2*125 = 3000 bits/second.
The tones are spaced by 187.5 Hz, the first is 500 Hz, the last
is 2687.5 Hz. The whole bandwidth is 100-200 Hz (on both sides)
larger than that. The modem seems to work better than my previous
multi-tone DBPSK one.

Infact it's up to the user to define how many tones he need
and where should they be placed - the code is flexible in this respect,
so one can easily adapt the data rate to the available bandwidth.

The modem's encoder and decoder is based on the 128 point FFT
at 8000 Hz sampling.

The modem works on my DSPCARD4 with the build-in KISS-TNC
or in the test mode so you can spy on various internal data.
In principle it should work too on the EVM56002 with the Johan's
BIOS.ASM - I am going to try this. My other applications did work
so I don't expect a problem there.

No FEC yet, but I am thinking of it. First I should make
some provision for soft decisions, then interleave, then FEC.

The other thing to think about: how to make such FFT decoder
"tuneable" so it could accept a signal shifted in frequency.
For the moment the decoder can detect a mis-tune, but is not able
to correct it.

Pawel
From FORRERJ@frl.orst.edu Thu Jun 22 10:51:26 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA20115 for <hfsig@tapr.org>; Thu, 22 Jun 1995 10:50:58 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA25692 for <hfsig@tapr.org>; Thu, 22 Jun 1995 08:37:28 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 22 Jun 95 8:43:59 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 22 Jun 95 8:43:51 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 22 Jun 1995 08:43:45 PST8PDT
Subject:       Re: [HFSIG:428] Re: HFSIG activities
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <3272701710E@frl.orst.edu>

Pawel,

Excellent! If you have the foundation of something that has promise, 
perhaps it is time that we can divide the task up and let a couple of folks 
work on it. Just off the top of my head I can think of a couple of them:

1) Tuning indicator
2) Frequency tune-up/correction
3) ECC
4) Simple KISS-based user-interface instead of NOS so that we can
   get at testing the modem. The idea is that NOS compatibilty be
   retained for future networking applications.

These are quite general in nature, so you probably still could change things
at the very low implementation level and use the higher levels of
code.

What do you think - anyone interested in working on some of these topics?

73's
--Johan, KC7WW   
From RHIII@delphi.com Thu Jun 22 13:23:46 1995
Received: from bos1g.delphi.com (bos1g.delphi.com [192.80.63.9]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA21874 for <hfsig@tapr.org>; Thu, 22 Jun 1995 13:23:41 -0500
From: RHIII@delphi.com
Received: from delphi.com by delphi.com (PMDF V4.3-9 #10880)
 id <01HS0D1FMF9I94GYEZ@delphi.com>; Thu, 22 Jun 1995 14:23:34 -0400 (EDT)
Date: Thu, 22 Jun 1995 14:23:34 -0400 (EDT)
Subject: FAQ ?
To: hfsig@tapr.org
Message-id: <01HS0D1FMF9K94GYEZ@delphi.com>
X-VMS-To: INTERNET"hfsig@tapr.org"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

Tremendous ideas and excellent writing on this list.  
Is there a FAQ supporting it ?

---Richard/NT2Z
From paulr@hagar.udc.neweast.ca Tue Jun 27 08:17:12 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id IAA11271 for <hfsig@tapr.org>; Tue, 27 Jun 1995 08:16:45 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA08228; Tue, 27 Jun 95 13:15:49 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA804275155; Tue, 27 Jun 95 10:45:43 nst
Date: Tue, 27 Jun 95 10:45:43 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Message-Id: <9505278042.AA804275155@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:428] Re: HFSIG activities

>>The other thing to think about: how to make such FFT 
decoder "tuneable" so it could accept a signal shifted in 
frequency.
For the moment the decoder can detect a mis-tune, but is not able 
to correct it.

Pawel<<


Try a Zero-Padded Larger FFT (Say 512pt) 
        8000/512 = 15.62Hz/bin

Although a zero-padded FFT will not resolve two tones that occupied
the same bin in a smaller FFT into their individual components, it will resolve 
where the peak power point is of a single tone to a more acurate point. Thus by 
calculating the magnitude on the bins adjacent to the bin expected to carry the 
data tone, you can choose which one you should interpret as best centred and to 
use for phase calculation. 

So a 512pt has 4 times more bins than a 128pt, allowing you to choose a bin 
closer to the true location of the received signal. You can thus compensate for 
radio offset without having to shift frequency with something like a hilbert 
transform, although I'm uncertain which would be more efficient in code 
execution time.

I don't know how much error would occur in choosing to use a more offset bin 
part way through a packet (in my simulations it was negligible with the angle in
the zero-padded FFT the same as in the smaller FFT), but I suspect the radio's 
frequency offset drift to be VERY slow. Thus choose the offset during the 
syncronization, and stick with it for the rest of the packet.

Note also that all the channels in the parallel modem would be shifted by the 
same amount of freq/bins (at the audio level since freq offset is at the RF 
level). So calculating the peak power point by adding together the magnitudes of
the corresponding bins at each channel over several symbols will average out 
which way the radio is offset even in the presence of noise.

How are you calculating the phase angle? I have an article on how to do a 
simplified arctan approx for a TMS32010 if its useful to anyone. I'm certain it 
could be recoded to any DSP.

Paul Russell
paulr@neweast.ca



From JALOCHA@chopin.ifj.edu.pl Tue Jun 27 10:30:26 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA12663 for <hfsig@tapr.org>; Tue, 27 Jun 1995 10:30:05 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id RAA09541 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Tue, 27 Jun 1995 17:28:37 +0200
Date: Tue, 27 Jun 1995 17:28 GMT+1
Subject: Re: [HFSIG:431] Re: HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <3BE65F09E022085A@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"


>Try a Zero-Padded Larger FFT (Say 512pt) 
>        8000/512 = 15.62Hz/bin
>
>Although a zero-padded FFT will not resolve two tones that occupied
>the same bin in a smaller FFT into their individual components, it will resolve 
>where the peak power point is of a single tone to a more acurate point. Thus by 
>calculating the magnitude on the bins adjacent to the bin expected to carry the 
>data tone, you can choose which one you should interpret as best centred and to 
>use for phase calculation. 

So you select the best tone, and then you may possibly be mis-tuned
by up to 7.8 Hz - this is still a lot... In term of phase changes:
7.8 Hz is about 49 radians/second, I transmit 125 symbols per second,
thus during one symbol the phase would turn by 0.39 radian (22 degrees)
- this is a lot, almost half way to make a bit error (45 degrees).
I know I could make even longer FFTs and get more finer steps...
I agree this is one way to deal with the problem.

I was actually thinking of a way to "interpolate" between the FFT bins.
If a tone falls say right inbetween bin 7 and 8 which combination
of the two you need to get the data as if the tone falls just right
into the bin's center ?
In other words how can you frequency-shift the frequency-domain data
by an arbitrary step ? I know how to do it with the time-domain data...

>So a 512pt has 4 times more bins than a 128pt, allowing you to choose a bin 
>closer to the true location of the received signal. You can thus compensate for 
>radio offset without having to shift frequency with something like a hilbert 
>transform, although I'm uncertain which would be more efficient in code 
>execution time.

Hilbert transform can shift the frequency ? This might be something
I am looking for ?

>I don't know how much error would occur in choosing to use a more offset bin 
>part way through a packet (in my simulations it was negligible with the angle in
>the zero-padded FFT the same as in the smaller FFT), but I suspect the radio's 
>frequency offset drift to be VERY slow. Thus choose the offset during the 
>syncronization, and stick with it for the rest of the packet.

This is my current "research" direction. I am thinking of making a header
such that the receiver may quickly acquire the frequency shift and
the symbol sync. - possibly both at same time. After the header has passed
only minor adjustments are to be made.

>Note also that all the channels in the parallel modem would be shifted by the 
>same amount of freq/bins (at the audio level since freq offset is at the RF 
>level). So calculating the peak power point by adding together the magnitudes of
>the corresponding bins at each channel over several symbols will average out 
>which way the radio is offset even in the presence of noise.

There is a little problem that the bands of the tones partially overlap
or are at least well packed so you may not be able to find a clear peak.
The could be overcome by sending only every second tone for the header.

>How are you calculating the phase angle? I have an article on how to do a 
>simplified arctan approx for a TMS32010 if its useful to anyone. I'm certain it 
>could be recoded to any DSP.

I don't really compute the phase angle but compare the two succesive I/Q
vectors. If A(a vector) is what I got from the current FFT and B is what
I got from the previous FFT I compute: X=B*A and Y=B'*A.
* means the vector-dot-product, ' means turning a vector by +90 degrees.
X and Y (infact a vector) contains the information to find one the di-bit
transmitted.

Anyway, I am certainly interrested in a fast way to compute
the phase from the the X/Y values.

I made more progress with the intersymbol crosstalk: I parametrized
the window's shape and by minimizing the total crosstalk in terms
of the parameters (I used praxis.zip found in msdos/math on most
FTP sites) I found an optimal shape with crosstalk at 0.6E-4
(it used to be 1E-1). The price for much lower crosstalk was the first
side-lobe at about -10dB level... but futher side-lobes are below -50dB
(measured with a soundcard + FREQ4 software).

Pawel
From JALOCHA@chopin.ifj.edu.pl Tue Jun 27 10:53:38 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA12800 for <hfsig@tapr.org>; Tue, 27 Jun 1995 10:53:27 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id RAA09829 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Tue, 27 Jun 1995 17:52:27 +0200
Date: Tue, 27 Jun 1995 17:52 GMT+1
Subject: Re: [HFSIG:429] Re: HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <3F38291EC022085A@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

>Excellent! If you have the foundation of something that has promise, 
>perhaps it is time that we can divide the task up and let a couple of folks 
>work on it. Just off the top of my head I can think of a couple of them:

>From my point of view these are the major problems:

1. Tunning correction: 10 Hz mis-tune seems to be real bad, and 20 Hz
   makes the signal unreadable even for 100 dB S/N :-)
   We probably need to make it automatic at least within a small range.
   For network application, the packet's header should be made for
   fast auto-retune and symbol-sync.

2. FEC with soft-decisions... how do we judge on the "strength"
   of the received symbol ?
   Here comes a related issue: if you want to compare the "strength"
   of symbols coming from different tones, you should normalize
   them somehow - this is trivial if you use division, but division
   is rather costly (in terms of clock cycles) for the DSPs.

   So an algorythm is needed which least divisions possible.
   I find my radio's (YEASU FT757-GXII) audio characteristic to be very
   unperfect: 2500 Hz tone is 2-3 times lower in amplitude than
   the 800 Hz tone (this is just the receiver). Well, this could be
   "perfect" for voice, but not for data.

   Another issue related to "band equalization" is the symbol
   synchronization. For the moment I am taking the average symbol
   shift from all 12 tones. But in general you want to keep the proper sync.
   even if one or more tones get overcome by a strong carrier-type
   interference. Thus you should weight the shifts from different carriers.

Pawel
From paulr@hagar.udc.neweast.ca Tue Jun 27 13:23:56 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAA14425 for <hfsig@tapr.org>; Tue, 27 Jun 1995 13:23:51 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA09841; Tue, 27 Jun 95 18:23:48 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA804293635; Tue, 27 Jun 95 15:53:30 nst
Date: Tue, 27 Jun 95 15:53:30 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Message-Id: <9505278042.AA804293635@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Pawel?

Pawel,

I'll send the file about angle calculations, but my mail server 
is eating your email reply address, please send it. The 13K file 
is maybe a bit long for posting here - unless several people want 
it??

I tried asking the tapr.org listserver for the subscribers, but 
it indicates that all of us are hidden names - Oh well (Guess 
that helps keep down people using our names for other 
purposes...).

>>>Here is the current list of non-concealed subscribers:
>>>Total number of subscribers: 144 (0 shown here)

There are definitely more subscribers than I thought.

Paul
paulr@neweast.ca

From nash@camail.ca.nmp.nokia.com Wed Jun 28 04:19:35 1995
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA22821 for <hfsig@tapr.org>; Wed, 28 Jun 1995 04:19:30 -0500
Received: from mgw.nmp.nokia.com (mgw.nmp.nokia.com [131.228.233.85]) by noknic.nokia.com (8.6.9/8.6.9) with SMTP id MAA29723 for <hfsig@tapr.org>; Wed, 28 Jun 1995 12:18:57 +0300
Message-Id: <199506280918.MAA29723@noknic.nokia.com>
Received: from caits1.ca.nmp.nokia.com by mgw.nmp.nokia.com with SMTP
	(1.38.193.4/16.2) id AA05931; Wed, 28 Jun 1995 12:18:55 +0300
Received: from cadsp1.ca.nmp.nokia.com by camail.ca.nmp.nokia.com with SMTP
	(1.37.109.14/16.2) id AA121751042; Wed, 28 Jun 1995 10:17:22 +0100
Date: Wed, 28 Jun 1995 10:17:22 +0100
From: Adrian Nash <nash@camail.ca.nmp.nokia.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:433] Re: HFSIG activities

Hi Pawel

I have a few suggestions which have worked in my MFSK modem which I suppose is
very similar in some respects.

>1. Tunning correction: 10 Hz mis-tune seems to be real bad, and 20 Hz
>   makes the signal unreadable even for 100 dB S/N :-)
>   We probably need to make it automatic at least within a small range.
>   For network application, the packet's header should be made for
>   fast auto-retune and symbol-sync.

There is a simple equation which uses the magnitudes (NOT magnitude squared) of
adjacent FFT points to calculate frequency error to within the separation of the
points. I have used this in my MFSK modem to track frequency error with some
success. However, I can't remember the formula off the top of my head! I'll get
back to you with this. I think Johan Forrer may be able to help you with this one.
He originally suggested the idea to me and I then produced a MathCad simulation
which worked, so then I coded it up in my modem and it works fine for tracking.

I use a Hilbert transform coupled to a complex demodulator to shift the audio
down to zero-IF in the complex plane. The tracking loop is closed by applying
the exact offset in Hz to the NCO algorithm.

>2. FEC with soft-decisions... how do we judge on the "strength"
>   of the received symbol ?
>   Here comes a related issue: if you want to compare the "strength"
>   of symbols coming from different tones, you should normalize
>   them somehow - this is trivial if you use division, but division
>   is rather costly (in terms of clock cycles) for the DSPs.

For soft decisions, I use the following equation which unfortunately does have
a divide in it. However, the divide only needs to be performed once in the case
of an MFSK modem or 12 times in your case for the 12 best signals:

	           2
	  2       I (best)
         C   =   ----------
	  n       ---2
                  \ I
                  /  k
                  ---

ie, accumulate the magnitude squared results (I^2+Q^2) then find the best 
(ie greatest) magnitude. Divide one by the other. C(n)^2 is then a good indicator
of the "goodness" or confidence of the particular tone. and is fine for
soft decision use. On my ADSP2101-based modem, the divide is done in floating
point and takes about 30 cycles (about 1.5us on ADSP2115) including conversion
back to fixed point.

Regards
Adrian
From forrerj@ucs.orst.edu Wed Jun 28 10:47:53 1995
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id KAA25279 for <hfsig@tapr.org>; Wed, 28 Jun 1995 10:47:47 -0500
Received: from p04.t0.monrotel.com by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM)
	id AA24218; Wed, 28 Jun 1995 08:47:14 -0700
Message-Id: <9506281547.AA24218@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 28 Jun 1995 07:58:21 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:432] Re: HFSIG activities

Pawel,


>Hilbert transform can shift the frequency ? This might be something
>I am looking for ?
>


It may be useful to use a Hilbert transform especially if your demodulator
require I/Q paths, i.e. doing complex FFT's. You do need, however, some good
low pass filters to go with it. All these computational blocks eats at your
machine ticks, however. If you can fit it in, that will be excellent. We had
some discussion about this topic under "HF channel simulator". 


>I made more progress with the intersymbol crosstalk: I parametrized
>the window's shape and by minimizing the total crosstalk in terms
>of the parameters (I used praxis.zip found in msdos/math on most
>FTP sites) I found an optimal shape with crosstalk at 0.6E-4
>(it used to be 1E-1). The price for much lower crosstalk was the first
>side-lobe at about -10dB level... but futher side-lobes are below -50dB
>(measured with a soundcard + FREQ4 software).
>

For interest sake, could you perhaps tell us a bit more about the FREQ4
software - where to obtain it etc. These analytical methods and tools are
useful to know about.

                              --------------------

I also had an interesting e-mail from Adrian, G4ZHZ about his progress with
his Piccolo (MFSK) project. As you all know, he is using a DSP sound card
and he tells me that he has done a lot of work on the DSP kernel (that part
of the DSP code that runs in real time, in parallel with other DSP
activities - mainly to orchestrate tasks and communicate with the host PC).
This was necessary before he could start porting his exsisting Piccolo code
to the DSP. These extensions also are quite general, as a matter of fact he
built a very nice audio signal processing box using that. This audio
processor is intended for use with your HF radio and includes: various
filters (narrow CW etc.), denoisers, and a software BFO to resolve slightly,
off-tune SSB or CW. One can quite easily see how these different functions
plays a role in his modem developments. The sound procesor, though would be
a handy piece of code in its own right. I am looking forward testing it out.
Good work Adrian!


73's

--Johan

From GTaylor@ecad00.avionics.itt.com Wed Jun 28 14:03:31 1995
Received: from ittingw.itt.com (ittingw.itt.com [151.190.254.250]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id OAA27788 for <hfsig@tapr.org>; Wed, 28 Jun 1995 14:03:28 -0500
Received: from ccmail.avionics.itt.com by ecad00.avionics.itt.com (5.65/Ultrix3.0-C)
	id AA23104; Wed, 28 Jun 1995 14:59:55 -0400
Received: from cc:Mail by CCMAIL.AVIONICS
	id AA804376746; Wed, 28 Jun 95 14:41:14 EST
Date: Wed, 28 Jun 95 14:41:14 EST
From: "Taylor, Gregg" <GTaylor@ecad00.avionics.itt.com>
Message-Id: <9505288043.AA804376746@CCMAIL.AVIONICS>
To: hfsig@tapr.org
Cc: Henry_Sonntag_at_ITTAVI@CCMAIL.AVIONICS.itt.com
Return-Receipt-To: GTaylor@ecad00.avionics.itt.com
Subject: ADDRESSING PROBLEM

From 72253.2602@compuserve.com Thu Jun 29 10:29:36 1995
Received: from arl-img-4.compuserve.com (arl-img-4.compuserve.com [198.4.7.4]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA04599 for <hfsig@tapr.org>; Thu, 29 Jun 1995 10:29:33 -0500
Received: by arl-img-4.compuserve.com (8.6.10/5.950515)
	id LAA27535; Thu, 29 Jun 1995 11:29:31 -0400
Date: 29 Jun 95 11:27:27 EDT
From: Peter Schulze <72253.2602@compuserve.com>
To: TAPR-HFSIG <hfsig@tapr.org>
Subject: Freq anal. with soundcards
Message-ID: <950629152726_72253.2602_EHJ164-1@CompuServe.COM>

> For interest sake, could you perhaps tell us a bit more about the FREQ4
> software - where to obtain it etc. These analytical methods and tools are
> useful to know about.


There are several freeware programs around that allow spectrum
analysis with soundcards :

1.- MICFFT
by Craig Walsh (walsh@biovx1.DNET.NASA.GOV)
This one works on almost any 'compatible' soundcard. 
Craig told me that he is working on a windows version. 
The most current Version is 1.2.
Micfft can be found in the Compuserve Soundblaster forum (MICFFT.ZIP).
There was an article by DK4ZC about using this program to analyse
HF digital signals in the March issue of the ADRS Digital 
Journal.
MicFFTs main limitation is slow execution and a FFT length of max 256
points. On the other hand it is very stable, has nice graphics and works on 
about every Hardware. MicFFT is freeware.

2. FREQ3, FREQ4 and SPECGRAM

by Philip VanBaren
Internet:    phillipv@engin.umich.edu
Compuserve:  71214,2302
1845 Lake Lila Dr.  Apt. C3
Ann Arbor, MI  48105

..also Freeware.
can be found on Compuserve as well, in the same forum (.ZIP).
Freq3 is an older Version but comes with sourcecode (Borland C++). 
FREQ3 was written for the Pro Audio Spectrum 16. FREQ4 also
supports the Soundblaster cards. 
Main advantages against  MicFFT:
- FFT Length variabel, max. 2048 points
- a lot faster (31ms for a 1024 FFT on a 486/33)
- with PAS cards up to 44KHz at 16 bit Resolution
- SPECGRAM has an excellent graphical Display on SVGA.
- lots of commandline options
- FREQ3 sourcecode avaiable.
(thanks to Christoph dl4rcg who supplied the FREQ info to me some time ago) 

3. Another usefull program is Mathplot 
by Phillip H. Sherrod
4410 Gerald Place
Nashville, TN  37205-3806 USA
615-292-2881 (evenings)
Internet: 76166.2640@compuserve.com
(shareware, uncrippled registration $25, also on the CIS soundblaster forum).
Mathplot is a mathematical function plotting system which allows you to
enter functions using ordinary algebraic notation and immediately plot them.
Cartesian, polar, and parametric functions are supported, and up to four
functions may be displayed simultaneously. A variety of built-in functions
are provided.  Plotting commands may be executed from command files.

Maybe someone who is on Compuserve as well can download these programs and
post them here on the TAPR system ? 
Unfortunatly i can't do that as i am on a very (!) 
expensive (-2400 baud X25) line, 
where i am charged 15 cents per kilobyte. 
So moving these files out of Cis and up here
would cost me a little fortune. The Datahighway did not
arrive in Africa yet(?).... 

73 Peter TY1PS


From forrerj@ucs.orst.edu Fri Jun 30 09:25:16 1995
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA17775 for <hfsig@tapr.org>; Fri, 30 Jun 1995 09:25:05 -0500
Received: from p05.t0.monrotel.com by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM)
	id AA26115; Fri, 30 Jun 1995 07:24:56 -0700
Message-Id: <9506301424.AA26115@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 30 Jun 1995 06:36:11 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:438] Freq anal. with soundcards

Peter,

Thanks for the interesting summary. Time that I explore some of those
mentioned programs. 

For interest sake, I may just add that the sound card FFT scope (on
hfsig/upload) will also be helpful, so will Tom McDermot's program for the
DSP-93, that does the same thing. I am just not certain about whether the
frequency resolution is sufficient.



--Johan, KC7WW


>> For interest sake, could you perhaps tell us a bit more about the FREQ4
>> software - where to obtain it etc. These analytical methods and tools are
>> useful to know about.
>
>
>There are several freeware programs around that allow spectrum
>analysis with soundcards :
>
>1.- MICFFT
>by Craig Walsh (walsh@biovx1.DNET.NASA.GOV)
>This one works on almost any 'compatible' soundcard. 
>Craig told me that he is working on a windows version. 
>The most current Version is 1.2.
>Micfft can be found in the Compuserve Soundblaster forum (MICFFT.ZIP).
>There was an article by DK4ZC about using this program to analyse
>HF digital signals in the March issue of the ADRS Digital 
>Journal.
>MicFFTs main limitation is slow execution and a FFT length of max 256
>points. On the other hand it is very stable, has nice graphics and works on 
>about every Hardware. MicFFT is freeware.
>
>2. FREQ3, FREQ4 and SPECGRAM
>
>by Philip VanBaren
>Internet:    phillipv@engin.umich.edu
>Compuserve:  71214,2302
>1845 Lake Lila Dr.  Apt. C3
>Ann Arbor, MI  48105
>
>.also Freeware.
>can be found on Compuserve as well, in the same forum (.ZIP).
>Freq3 is an older Version but comes with sourcecode (Borland C++). 
>FREQ3 was written for the Pro Audio Spectrum 16. FREQ4 also
>supports the Soundblaster cards. 
>Main advantages against  MicFFT:
>- FFT Length variabel, max. 2048 points
>- a lot faster (31ms for a 1024 FFT on a 486/33)
>- with PAS cards up to 44KHz at 16 bit Resolution
>- SPECGRAM has an excellent graphical Display on SVGA.
>- lots of commandline options
>- FREQ3 sourcecode avaiable.
>(thanks to Christoph dl4rcg who supplied the FREQ info to me some time ago) 
>
>3. Another usefull program is Mathplot 
>by Phillip H. Sherrod
>4410 Gerald Place
>Nashville, TN  37205-3806 USA
>615-292-2881 (evenings)
>Internet: 76166.2640@compuserve.com
>(shareware, uncrippled registration $25, also on the CIS soundblaster forum).
>Mathplot is a mathematical function plotting system which allows you to
>enter functions using ordinary algebraic notation and immediately plot them.
>Cartesian, polar, and parametric functions are supported, and up to four
>functions may be displayed simultaneously. A variety of built-in functions
>are provided.  Plotting commands may be executed from command files.
>
>Maybe someone who is on Compuserve as well can download these programs and
>post them here on the TAPR system ? 
>Unfortunatly i can't do that as i am on a very (!) 
>expensive (-2400 baud X25) line, 
>where i am charged 15 cents per kilobyte. 
>So moving these files out of Cis and up here
>would cost me a little fortune. The Datahighway did not
>arrive in Africa yet(?).... 
>
>73 Peter TY1PS
>
>
>

